[lldb-dev] VMRange merging in ProcessElfCore and DoReadMemory

Piotr Rak piotr.rak at gmail.com
Sat Feb 22 03:46:49 PST 2014 

Hi Ed

Sorry for late reply and thanks for looking into it.

Your example fails same way as mine for all combinations static/dynamic
gcc/clang.
Wonder if FreeBSD adds .text section to core files.

What would be result of disassembly for you?

For me it always looks like that:

dis -b -f
libc.so.6`__GI_raise:
   0x7f72a9b11330:  00 00  addb   %al, (%rax)
   0x7f72a9b11332:  00 00  addb   %al, (%rax)
   0x7f72a9b11334:  00 00  addb   %al, (%rax)
   0x7f72a9b11336:  00 00  addb   %al, (%rax)
   0x7f72a9b11338:  00 00  addb   %al, (%rax)
   0x7f72a9b1133a:  00 00  addb   %al, (%rax)
   0x7f72a9b1133c:  00 00  addb   %al, (%rax)
   0x7f72a9b1133e:  00 00  addb   %al, (%rax)
   0x7f72a9b11340:  00 00  addb   %al, (%rax)
   0x7f72a9b11342:  00 00  addb   %al, (%rax)
   0x7f72a9b11344:  00 00  addb   %al, (%rax)
   0x7f72a9b11346:  00 00  addb   %al, (%rax)
   0x7f72a9b11348:  00 00  addb   %al, (%rax)
...

Could you please compare output of readelf/eu-readelf with mine?

For me it is:
eu-readelf -l core_lnx.1125

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz
 MemSiz   Flg Align
  NOTE           0x000388 0x0000000000000000 0x0000000000000000 0x001940
0x000000     0x0
  LOAD           0x002000 0x0000000000400000 0x0000000000000000 0x000000
0x0c2000 R E 0x1000
  LOAD           0x002000 0x00000000004c2000 0x0000000000000000 0x003000
0x003000 RW  0x1000
  LOAD           0x005000 0x00000000004c5000 0x0000000000000000 0x006000
0x006000 RW  0x1000
  LOAD           0x00b000 0x0000000001906000 0x0000000000000000 0x002000
0x002000 RW  0x1000
  LOAD           0x00d000 0x0000000001908000 0x0000000000000000 0x000000
0x021000 RW  0x1000
  LOAD           0x00d000 0x00007f6e4be02000 0x0000000000000000 0x001000
0x001000     0x1000
  LOAD           0x00e000 0x00007f6e4be03000 0x0000000000000000 0x800000
0x800000 RW  0x1000
  LOAD           0x80e000 0x00007f6e4c603000 0x0000000000000000 0x001000
0x001000     0x1000
  LOAD           0x80f000 0x00007f6e4c604000 0x0000000000000000 0x800000
0x800000 RW  0x1000
  LOAD           0x100f000 0x00007f6e4ce04000 0x0000000000000000 0x001000
0x001000     0x1000
  LOAD           0x1010000 0x00007f6e4ce05000 0x0000000000000000 0x800000
0x800000 RW  0x1000
  LOAD           0x1810000 0x00007fffcef2b000 0x0000000000000000 0x022000
0x022000 RW  0x1000
  LOAD           0x1832000 0x00007fffceffe000 0x0000000000000000 0x002000
0x002000 R E 0x1000
  LOAD           0x1834000 0xffffffffff600000 0x0000000000000000 0x001000
0x001000 R E 0x1000

I am mostly interested if your core contain for .text sections is non-zero
length for phdrs in loaded segments:

For me program .text is not clearly there:
LOAD           0x002000 0x0000000000400000 0x0000000000000000 0x000000
0x0c2000 R E 0x1000

                                  ~~~~~~
That would explain the difference for what I and you see.

IIRC Target::ReadMemory seems to be using m_images at first, but after
DynamicLoader kicks in it uses:

bytes_read = m_process_sp->ReadMemory(load_addr, dst, dst_len, error);


which obviously returns only zeros for me since core did not contain
any data for .text sections.


I wonder if:



section_load_list.ResolveLoadAddress (load_addr, resolved_addr);


is doing right thing for me, but I clearly do not understand yet how it
works and how should it work.


I'll be looking into it more later today and tomorrow.


Cheers,
/Piotr


2014-02-20 15:30 GMT+01:00 Ed Maste <emaste at freebsd.org>:

> On 19 February 2014 19:09, Piotr Rak <piotr.rak at gmail.com> wrote:
> > If you want to give it a shot, I'll attach one of my puppets (10
> threads, doing nothing but sleep).
> > Also I use bfd linker so it has nothing to do with gold in my case.
>
> Hi Piotr,
>
> I'm not able to compile your test code (clang 3.4), but as a data
> point I have no trouble with a similar C test case of mine, on
> FreeBSD.  Perhaps you can build it and compare.
>
> My test code is here: https://github.com/emaste/userland-cores
>
> (lldb) bt all
> * thread #1: tid = 0, 0x0000000800aa03fc libc.so.7`__sys_thr_kill + 12
> at thr_kill.S:3, name = 'gen-core-v1', stop reason = signal SIGABRT
>   * frame #0: 0x0000000800aa03fc libc.so.7`__sys_thr_kill + 12 at
> thr_kill.S:3
>     frame #1: 0x0000000800b4487b libc.so.7`abort + 75 at abort.c:65
>     frame #2: 0x00000000004007c1
> gen-core-v1`thread_fn_2(arg=0x0000000000600c20) + 81 at gen-core.c:37
>     frame #3: 0x0000000800822dc4
> libthr.so.3`thread_start(curthread=0x0000000801008000) + 260 at
> thr_create.c:284
>
>   thread #2: tid = 1, 0x0000000800b2707c libc.so.7`__sys_nanosleep +
> 12 at nanosleep.S:3, name = 'gen-core-v1', stop reason = signal
> SIGABRT
>     frame #0: 0x0000000800b2707c libc.so.7`__sys_nanosleep + 12 at
> nanosleep.S:3
>     frame #1: 0x0000000800a929c8 libc.so.7`__sleep(seconds=60) + 40 at
> sleep.c:58
>     frame #2: 0x0000000800825078 libthr.so.3`___sleep(seconds=60) + 40
> at thr_syscalls.c:592
>     frame #3: 0x0000000000400755
> gen-core-v1`thread_fn_1(arg=0x0000000000600c08) + 69 at gen-core.c:23
>     frame #4: 0x0000000800822dc4
> libthr.so.3`thread_start(curthread=0x0000000801007c00) + 260 at
> thr_create.c:284
>
>   thread #3: tid = 2, 0x0000000800b2707c libc.so.7`__sys_nanosleep +
> 12 at nanosleep.S:3, name = 'gen-core-v1', stop reason = signal
> SIGABRT
>     frame #0: 0x0000000800b2707c libc.so.7`__sys_nanosleep + 12 at
> nanosleep.S:3
>     frame #1: 0x0000000800a929c8 libc.so.7`__sleep(seconds=60) + 40 at
> sleep.c:58
>     frame #2: 0x0000000800825078 libthr.so.3`___sleep(seconds=60) + 40
> at thr_syscalls.c:592
>     frame #3: 0x0000000000400755
> gen-core-v1`thread_fn_1(arg=0x0000000000600bf0) + 69 at gen-core.c:23
>     frame #4: 0x0000000800822dc4
> libthr.so.3`thread_start(curthread=0x0000000801007800) + 260 at
> thr_create.c:284
>
>   thread #4: tid = 3, 0x0000000800b2707c libc.so.7`__sys_nanosleep +
> 12 at nanosleep.S:3, name = 'gen-core-v1', stop reason = signal
> SIGABRT
>     frame #0: 0x0000000800b2707c libc.so.7`__sys_nanosleep + 12 at
> nanosleep.S:3
>     frame #1: 0x0000000800a929c8 libc.so.7`__sleep(seconds=60) + 40 at
> sleep.c:58
>     frame #2: 0x0000000800825078 libthr.so.3`___sleep(seconds=60) + 40
> at thr_syscalls.c:592
>     frame #3: 0x000000000040088f gen-core-v1`main(argc=1,
> argv=0x00007fffffffd540) + 191 at gen-core.c:54
>     frame #4: 0x0000000000400681 gen-core-v1`_start(ap=<unavailable>,
> cleanup=<unavailable>) + 161 at crt1.c:97
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140222/5e625dce/attachment.html>

More information about the lldb-dev mailing list