LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 18734 - symbol lookup of bss variable in shared library chooses one from shared library instead of from executable
Summary: symbol lookup of bss variable in shared library chooses one from shared libra...
Status: NEW
Alias: None
Product: lldb
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: 3.3
Hardware: PC FreeBSD
: P normal
Assignee: LLDB commit list
URL: https://gist.github.com/HarryWeppner/...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-05 01:34 PST by Harry Weppner
Modified: 2014-03-28 16:17 PDT (History)
2 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Harry Weppner 2014-02-05 01:34:23 PST 
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.
Comment 1 emaste 2014-02-11 12:14:55 PST 
Would you mind adding your exact compile / link steps?
Comment 2 Harry Weppner 2014-02-11 15:37:32 PST 
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>
Comment 3 Harry Weppner 2014-02-18 11:57:14 PST 
Is there any other info I can provide to help identify the root cause?
Comment 4 emaste 2014-02-26 20:17:55 PST 
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.
Comment 5 Harry Weppner 2014-03-04 09:26:35 PST 
Hi,

what's the next step in investigating further?

Thanks & cheerio, Harry.
Comment 6 Harry Weppner 2014-03-28 16:17:09 PDT 
Is there _anything_ I can do to support the analysis of this bug?

Thanks & cheerio, Harry.