[lldb-dev] Linux Core Dump and Symbol resolution

Samuel Jacob samueldotj at gmail.com
Wed Feb 13 16:35:21 PST 2013


Greg and others,

Update on the Linux coredump:
It works if use "image load --file xxx .text yyyy".

$ Release+Asserts/bin/lldb
(lldb) target create -c ~/test/core
Core file '/mts/home3/jacobs/test/core' (x86_64) was loaded.
Process 0 stopped
* thread #1: tid = 0x0000, 0x00000000004004c4, stop reason = signal SIGCONT
    frame #0: 0x00000000004004c4
-> 0x4004c4:  movb   $0, (%rax)
   0x4004c7:  popq   %rbp
   0x4004c8:  ret
   0x4004c9:  pushq  %rbp
(lldb) target modules add ~/test/a.out
(lldb) image load --file ~/test/a.out .text 0x4003d0
section '.text' loaded at 0x4003d0
(lldb) bt
* thread #1: tid = 0x0000, 0x00000000004004c4 a.out`function4(arg=0) + 16
at test.c:4, stop reason = signal SIGCONT
    frame #0: 0x00000000004004c4 a.out`function4(arg=0) + 16 at test.c:4
    frame #1: 0x00000000004004d7 a.out`function3 + 11 at test.c:8
    frame #2: 0x00000000004004e7 a.out`function2(arg=4195559) + 11 at
test.c:11
    frame #3: 0x00000000004004f7 a.out`function1(arg1=0,
arg2=140736328348032, str=0x00000000004004e7) + 3 at test.c:15
    frame #4: 0x0000000000400507 a.out`function1(arg1=0,
arg2=140736328348048, str=0x00000000004004f7) + 19 at test.c:15

I didnt try this previously since I thought AUXV->AT_ENTRY processing is
needed only if the load address is different.
Is there a reason why lldb is not using the symbol files virtual address as
load address if load is not provided?

$eu-readelf -S ~/test/a.out  | grep .text
[13] .text                PROGBITS     00000000004003d0 000003d0 00000238
 0 AX     0   0 16

$eu-readelf -n ~/test/core | grep ENTRY
    ENTRY: 0x4003d0

I tried running lldb on few core files and all worked fine.
I will send the patch once I complete the following
1) Insert thread name, signal values
2) Insert AT_ENTRY
3) Add comments to the code
4) More testing

Thanks
Samuel



On Fri, Feb 8, 2013 at 3:00 PM, Samuel Jacob <samueldotj at gmail.com> wrote:

> Hi,
>
> I am new to lldb and creating a patch to support Linux coredumps.
> This plugin is based on mach-core plugin.
> Currently it can parss the NOTE segments and loads all the threads found
> in the corefile(x86_64).
> That is "thread list" works fine.
>
> It also reads the PRSTATUS structure and populates the register
> infromation.
> That is "register read" works fine.
>
> However lldb is not using the symbol files while using the core file.
> Because of this it is not using DWARF structures while creating frames.
> That is frame variables and arguments are not available. Also lldb not
> resolving address to symbols.
>
> $lldb
> (lldb) target create -c ./core
> Core file '/mts/home3/jacobs/test/core' (x86_64) was loaded.
> Process 0 stopped
> * thread #1: tid = 0x0000, 0x00000000004004c4, stop reason = signal SIGCONT
>     frame #0: 0x00000000004004c4
> error: core file does not contain 0x4004c4
> (lldb) target modules add ./a.out
> (lldb) image lookup --address  0x4004c4
>       Address: a.out[0x00000000004004c4] (a.out..text + 244)
>       Summary: a.out`function4 + 16 at test.c:4
> (lldb) bt
> * thread #1: tid = 0x0000, 0x00000000004004c4, stop reason = signal SIGCONT
>     frame #0: 0x00000000004004c4
>     frame #1: 0x00000000004004d7
>     frame #2: 0x00000000004004e7
>     frame #3: 0x00000000004004f7
>     frame #4: 0x0000000000400507
> (lldb) image lookup --address 0x00000000004004d7
>       Address: a.out[0x00000000004004d7] (a.out..text + 263)
>       Summary: a.out`function3 + 11 at test.c:8
>
> In the above example the IP's are not resolved to symbol in "bt" although
> lldb is able to resolve the addresses using "image lookukp" . What command
> should be used to link a target with symbol file?
>
> Here is the program that I used which compiled with "gcc -O0 -g3"
> $cat test.c
> void function4(unsigned int arg)
> {
>     char *local = 0;
>     *local = 0;
> }
> void function3()
> {
>     function4(-1);
> }
> void function2(long arg)
> {
>     function3();
> }
> void function1(int arg1, long arg2, char *str)
> {
>     function2(1);
> }
> void main()
> {
>     function1(0, 1L, "Test\n");
> }
>
> GDB output
>
> $gdb --quiet a.out core
> Reading symbols from /mts/home3/jacobs/test/a.out...done.
>
> warning: exec file is newer than core file.
> [New LWP 26718]
>
> warning: Can't read pathname for load map: Input/output error.
> Core was generated by `./a.out'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00000000004004c4 in function4 (arg=0) at test.c:4
> 4           *local = 0;
> (gdb) bt
> #0  0x00000000004004c4 in function4 (arg=0) at test.c:4
> #1  0x00000000004004d7 in function3 () at test.c:8
> #2  0x00000000004004e7 in function2 (arg=4195559) at test.c:11
> #3  0x00000000004004f7 in function1 (arg1=0, arg2=140736328348032,
> str=0x4004e7  <incomplete sequence \370\270>) at test.c:15
> #4  0x0000000000400507 in function1 (arg1=0, arg2=140736328348048,
> str=0x4004f7 "\345H\203\354\030\211}\374H\211u\360H\211U\350\277\001") at
> test.c:15
> #5  0x00007fbcdfe6c76d in __libc_start_main () from
> /lib/x86_64-linux-gnu/libc.so.6
> #6  0x00000000004003f9 in _start ()
>
> I can post the patch if anyone interested(but it needs to be cleaned up).
>
> Thanks
> Samuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130213/4dbfcb53/attachment.html>


More information about the lldb-dev mailing list