Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

symbol lookup of bss variable in shared library chooses one from shared library instead of from executable #19108

Open
llvmbot opened this issue Feb 5, 2014 · 6 comments
Open

symbol lookup of bss variable in shared library chooses one from shared library instead of from executable #19108

llvmbot opened this issue Feb 5, 2014 · 6 comments
Labels
bugzilla Issues migrated from bugzilla lldb

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 5, 2014

Bugzilla Link 18734
Version 3.3
OS FreeBSD
Reporter LLVM Bugzilla Contributor
CC @emaste

Extended Description

Hi,

I stumbled across a situation where the symbol lookup seems inconsistent.

The gist of the issue is described at https://gist.github.com/HarryWeppner/946cac154d769cf6936c

In line https://gist.github.com/HarryWeppner/946cac154d769cf6936c#file-lldb-L14
lldb prints that the address of variable 'a' is 0x800a1b820 within libbss.so.1 (the shared library created from mylib.c).

That value shows as 0 even after being set to 1, i.e. the expression a == i (https://gist.github.com/HarryWeppner/946cac154d769cf6936c#file-lldb-L24) is false . However, the printout in line https://gist.github.com/HarryWeppner/946cac154d769cf6936c#file-lldb-L28 is ok again and shows 'a' with a value of 1.

The fact that lldb and gdb show this behavior may indicate that the root cause is actually a backend bug but I've filed this bug here since the symptom occurs in lldb.

Thanks & cheerio, Harry.
@emaste
Copy link
Member

emaste commented Feb 11, 2014

Would you mind adding your exact compile / link steps?

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 11, 2014

Makefile for the lib (I called it bss):

LIB=bss
SHLIB=${LIB}
SHLIB_MAJOR=1

SRCS+=mylib.c

WITH_DEBUG_FILES=yes
DEBUGMKDIR=TRUE

.include "../Makefile.inc"

.include <bsd.lib.mk>

Makefile for the program "mytest"

PROG=mytest

WITH_DEBUG_FILES=yes

DPADD+=bss
LDADD+= -lbss
LDFLAGS+= -L${.CURDIR}/../lib

.include "../Makefile.inc"

.include <bsd.prog.mk>

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 18, 2014

Is there any other info I can provide to help identify the root cause?

@emaste
Copy link
Member

emaste commented Feb 27, 2014

The symbol 'a' does actually exist in both the executable and library:

joule% nm --print-file-name -D mytest lib/libbss.so | grep ' a$'
mytest:0000000000600c10 B a
lib/libbss.so:0000000000200810 B a

mytest includes space for the variable and uses a copy relocation; it seems that LLDB is incorrectly ending up with the (unused) one from the shared library instead of the one from the main executable.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 4, 2014

Hi,

what's the next step in investigating further?

Thanks & cheerio, Harry.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 28, 2014

Is there anything I can do to support the analysis of this bug?

Thanks & cheerio, Harry.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla lldb
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@emaste @llvmbot