Re: vdso handling

On 03/13/2014 08:23 AM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Alan Modra [mailto:[email protected]]
>> Sent: Thursday, March 13, 2014 2:02 AM
>> To: Cary Coutant
>> Cc: Doug Evans; Metzger, Markus T; [email protected];
>> [email protected]
>> Subject: Re: vdso handling
>>
>> On Wed, Mar 12, 2014 at 01:22:58PM -0700, Cary Coutant wrote:
>>>> I think a case can be made that gdb should be able to use the
>>>> "execution view" of the program here.
>>>> As for how to achieve that ... "Discuss." :-)
>>>
>>> Add a PT_DEBUG program header entry? The PT_DEBUG segment would
>> need
>>> to have a small header that allows the debugger to find .debug_abbrev,
>>> .debug_info, etc. (i.e., a mini section table). Or, just add
>>> individual program header entries for each of the standard debug
>>> sections: PT_DEBUG_ABBREV, PT_DEBUG_INFO, etc.
>>
>> Debug sections are not normally loaded.  For that reason I don't think
>> it makes any sense to specify program headers for them.  It wouldn't
>> help in the vdso case anyway, since the problem there is that you only
>> have the loaded part of the original ELF file.
> 
> The vdso contains a section table, as well.  When I hack
> bfd_from_remote_memory to create BFD sections from them similar
> to what elf_object_p does, I get the target sections that I wanted in GDB.

I got curious.  Indeed:

$ gdb --quiet /bin/ls
Reading symbols from /usr/bin/ls...(no debugging symbols found)...done.
(gdb) catch syscall
Catchpoint 1 (any syscall)
(gdb) r
Starting program: /usr/bin/ls

Catchpoint 1 (call to syscall brk), 0x000000323d0163fa in __brk (addr=addr@entry=0x0) at ../sysdeps/unix/sysv/linux/x86_64/brk.c:32
32        __curbrk = newbrk = (void *) INLINE_SYSCALL (brk, 1, addr);
(gdb) shell cat /proc/23042/maps|grep vdso
7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
(gdb) dump memory /tmp/vdso.so 0x7ffff7ffd000 0x7ffff7fff000
(gdb) q

$ objdump -h /tmp/vdso.so

/tmp/vdso.so:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .hash         00000040  ffffffffff700120  ffffffffff700120  00000120  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .dynsym       00000108  ffffffffff700160  ffffffffff700160  00000160  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .dynstr       0000005e  ffffffffff700268  ffffffffff700268  00000268  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .gnu.version  00000016  ffffffffff7002c6  ffffffffff7002c6  000002c6  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .gnu.version_d 00000038  ffffffffff7002e0  ffffffffff7002e0  000002e0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .note         0000003c  ffffffffff700318  ffffffffff700318  00000318  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .eh_frame_hdr 0000003c  ffffffffff700354  ffffffffff700354  00000354  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .eh_frame     00000138  ffffffffff700390  ffffffffff700390  00000390  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .dynamic      000000f0  ffffffffff7004c8  ffffffffff7004c8  000004c8  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  9 .rodata       00000020  ffffffffff7005b8  ffffffffff7005b8  000005b8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 __bug_table   0000000c  ffffffffff7005d8  ffffffffff7005d8  000005d8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .discard      00000006  ffffffffff7005e4  ffffffffff7005e4  000005e4  2**0
                  CONTENTS, ALLOC, LOAD, DATA
 12 .altinstructions 00000048  ffffffffff7005ea  ffffffffff7005ea  000005ea  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 13 .altinstr_replacement 00000012  ffffffffff700632  ffffffffff700632  00000632  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .text         0000069d  ffffffffff700700  ffffffffff700700  00000700  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .comment      0000002c  0000000000000000  0000000000000000  00000d9d  2**0
                  CONTENTS, READONLY

> The patch is rather big, though, and duplicating a lot of elf_object_p's code.

Why's that?  Why doesn't the memory-backed bfd paths take the same paths as
a file-backed bfd internally in bfd?  It sounds to me that this should be
doable without duplication.

-- 
Pedro Alves