Re: vdso handling

Pedro Alves
2014-03-13T10:07:20Z

On 03/13/2014 08:23 AM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Alan Modra [mailto:amodra@gmail.com]
>> Sent: Thursday, March 13, 2014 2:02 AM
>> To: Cary Coutant
>> Cc: Doug Evans; Metzger, Markus T; gdb@sourceware.org;
>> binutils@sourceware.org
>> 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