Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Oct 2019 10:09:18 +1100
From:      MJ <mafsys1234@gmail.com>
To:        Doug Hardie <bc979@lafn.org>, FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: Extension to previous posts: Problems with ld, libc, and "struct stat"
Message-ID:  <ccb4b6bc-df7e-eab5-bf41-085f979ad53e@gmail.com>
In-Reply-To: <E92C7F26-912F-4443-A37B-E7AF9E025CD8@mail.sermon-archive.info>
References:  <E92C7F26-912F-4443-A37B-E7AF9E025CD8@mail.sermon-archive.info>

next in thread | previous in thread | raw e-mail | index | archive | help

On 17/10/2019 8:02 am, Doug Hardie wrote:
> Here is an issue that has plagued me for some time:
>
> testlib.c:
> #include <sys/stat.h>
> #include <stdio.h>
> #include <string.h>
> #include <strings.h>
>
> char id[4];
> int sock;
>
> void testfunc() {
>    struct stat sb;
>    stat("testlib.c", &sb);
>    strcpy (id, "aa");
>    sock = 5;
>    printf("Size of testlib.c is %i bytes.\n", (int)sb.st_size);
> }
>
>
> testprog.c:
> #include <stdio.h>
>
> extern char id[4];
> extern int sock;
>
> void testfunc(void);
> int main(int argc, char **argv) {
>    testfunc();
>    printf ("id = %s\n", id);
>    printf ("sock = %d\n", sock);
>    return 0;
> }
>
>
> Makefile:
> all:    clean testprog run
>
> testprog:
>          cc -Wall -g -c -fPIC -o testlib.o testlib.c
>          cc  -shared -Wl,-export-dynamic -o testlib.so testlib.o
>          cc -Wall -g -o testprog ./testlib.so testprog.c
>
> clean:
>          rm -f testlib.o testlib.so testprog
>
> run:
>          ./testprog
>
>
> Using make:
> rm -f testlib.o testlib.so testprog
> cc -Wall -g -c -fPIC -o testlib.o testlib.c
> cc  -shared -Wl,-export-dynamic -o testlib.so testlib.o
> cc -Wall -g -o testprog ./testlib.so testprog.c
> ./testprog
> Size of testlib.c is 268 bytes.
> id = aa
> sock = 5
>
>
> Running lldb:
> master# lldb testprog
> (lldb) target create "testprog"
> Current executable set to 'testprog' (x86_64).
> (lldb) b main
> Breakpoint 1: where = testprog`main + 22 at testprog.c:8, address = 0x0000000000201366
> (lldb) r
> Process 34787 launching
> Process 34787 launched: '/home/doug/zzz/testprog' (x86_64)
> Process 34787 stopped
> * thread #1, name = 'testprog', stop reason = breakpoint 1.1
>      frame #0: 0x0000000000201366 testprog`main(argc=1, argv=0x00007fffffffeb38) at testprog.c:8
>     5   	
>     6   	void testfunc(void);
>     7   	int main(int argc, char **argv) {
> -> 8   	  testfunc();
>     9   	  printf ("id = %s\n", id);
>     10  	  printf ("sock = %d\n", sock);
>     11  	  return 0;
> (lldb) n
> Size of testlib.c is 268 bytes.
> Process 34787 stopped
> * thread #1, name = 'testprog', stop reason = step over
>      frame #0: 0x000000000020137f testprog`main(argc=1, argv=0x00007fffffffeb38) at testprog.c:9
>     6   	void testfunc(void);
>     7   	int main(int argc, char **argv) {
>     8   	  testfunc();
> -> 9   	  printf ("id = %s\n", id);
>     10  	  printf ("sock = %d\n", sock);
>     11  	  return 0;
>     12  	}
> (lldb) p id
> error: use of undeclared identifier 'id'
> (lldb) p sock
> error: Couldn't materialize: couldn't get the value of variable sock: testlib.so[0x4004] can't be resolved, testlib.so is not currently loaded
> error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
> (lldb) c
> id = aa
> sock = 5
> Process 34787 resuming
>
>
> You notice that lldb cannot display values for id or sock.  It even gives quite different messages about them.  However the program can access the values and it prints them out properly.  Why can't lldb see them?  How can that be corrected?
>
> What is even more interesting is that in the real application there are quite a few of these global variables and lldb can display some of them, just not all.  Possibly it has to do with the specific names as DATE generally works.  sock and id never seem to work.
>
> -- Doug

Well it's obviously wrong. It's a bug in lldb. Unless you have to specifically load the shared library in? (process load testlib?)

I tested this with gdb, it works as expected. That's probably why I still use gdb...


>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ccb4b6bc-df7e-eab5-bf41-085f979ad53e>