From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Doug Evans <xdje42@gmail.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: time to workaround libc/13097 in fsf gdb?
Date: Sun, 21 Sep 2014 19:12:00 -0000 [thread overview]
Message-ID: <541F2311.1040404@redhat.com> (raw)
In-Reply-To: <20140920213033.GA6255@host2.jankratochvil.net>
On 09/20/2014 10:30 PM, Jan Kratochvil wrote:
> On Fri, 19 Sep 2014 16:41:34 +0200, Pedro Alves wrote:
>> Here it is. WDYT?
> [...]
>> --- a/gdb/solib-svr4.c
>> +++ b/gdb/solib-svr4.c
> [...]
>> @@ -1478,6 +1479,42 @@ svr4_current_sos (void)
>> return svr4_current_sos_direct (info);
>> }
>>
>> +/* Implement the "current_sos" target_so_ops method. */
>> +
>> +static struct so_list *
>> +svr4_current_sos (void)
>> +{
>> + struct so_list *so_head = svr4_current_sos_1 ();
>> + struct objfile *objfile;
>> + struct obj_section *osect;
>> + CORE_ADDR vsyscall_addr = gdbarch_vsyscall_address (target_gdbarch ());
>> +
>> + /* Filter out the vDSO module, if present. Its symbol file would
>> + not be found on disk. The vDSO/vsyscall's OBJFILE is instead
>> + managed by symfile-mem.c:add_vsyscall_page. */
>> + if (vsyscall_addr != 0)
>> + {
>> + struct so_list **sop;
>> +
>> + sop = &so_head;
>> + while (*sop != NULL)
>> + {
>> + struct so_list *so = *sop;
>> +
>> + if (so->lm_info->l_addr_inferior == vsyscall_addr)
>
> This won't work as l_addr_inferior (and also l_addr) do not necessarily
> represent the real starting address of the ELF if the ELF itself is
> "prelinked". For some reason vDSOs on some kernels look like prelinked.
>
> kernel-3.16.2-200.fc20.x86_64 appears sane, vDSO is 0-based.
>
> But for example kernel-2.6.32-220.el6.x86_64 is "prelinked", see below.
Ah, didn't know that. That's the sort of thing we should have in
comments in the code, or at least in the commit log.
> That's the pain of solib-svr4.c which is OS-agnostic and so it cannot find out
> start of the ELF file just from link map. gdbserver can find it as it can
> depend on /proc/PID/{s,}maps as its linux-low.c is Linux-specific.
Is it really a pain though? We can just put things behind gdbarch hooks,
like my patch was doing. In fact, symfile-mem.c is already looking
at /proc/PID/maps to find the vdso mapping size. That's exactly done
behind a gdbarch hook:
args.size = 0;
if (gdbarch_find_memory_regions_p (target_gdbarch ()))
(void) gdbarch_find_memory_regions (target_gdbarch (),
find_vdso_size, &args);
>
> kernel-2.6.32-220.el6.x86_64
> (gdb) p *_r_debug.r_map.l_next
> $4 = {l_addr = 140737363566592, l_name = 0x3deba1ade4 "", l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188}
> (gdb) p/x *_r_debug.r_map.l_next
> $5 = {l_addr = 0x7ffff88fe000, l_name = 0x3deba1ade4, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188}
> # (gdb) p/x *new.lm_info
> # $5 = {l_addr = 0x0, l_addr_inferior = 0x7ffff88fe000, l_addr_p = 0x0, lm_addr = 0x3debc21718, l_ld = 0x7ffff7ffe580, l_next = 0x7ffff7ffd658, l_prev = 0x3debc21188, l_name = 0x3deba1ade4}
> (gdb) info auxv
> 33 AT_SYSINFO_EHDR System-supplied DSO's ELF header 0x7ffff7ffe000
> (gdb) info proc mappings
> 0x7ffff7ffe000 0x7ffff7fff000 0x1000 0 [vdso]
Sounds like a predicate like this would work then?
if (vsyscall_start <= so->lm_info->l_ld && so->lm_info->l_ld < vsyscall_end)
We would move the bit that finds the vdso size to the gdbarch_vsyscall_address hook,
and make that new hook return the vsyscall's size too in addition to
the starting address. We can also cache the result somewhere instead
of constantly reopening /proc/PID/maps if necessary.
We can also add a custom linux-specific target_so_ops implementation that
extends svr4's if we want. The target_so_ops to use is also registered
in the gdbarch.
CORE_ADDR vsyscall_start;
CORE_ADDR vsyscall_end;
vsyscall_start = gdbarch_vsyscall_address (target_gdbarch (), &vsyscall_end);
/* Filter out the vDSO module, if present. Its symbol file would
not be found on disk. The vDSO/vsyscall's OBJFILE is instead
managed by symfile-mem.c:add_vsyscall_page. */
if (vsyscall_start != 0)
{
struct so_list **sop;
sop = &so_head;
while (*sop != NULL)
{
struct so_list *so = *sop;
if (vsyscall_start <= so->lm_info->l_ld
&& so->lm_info->l_ld < vsyscall_end)
{
... found vdso ...
> (gdb) dump memory vdso.bin 0x7ffff7ffe000 0x7ffff7fff000
> # readelf -Wa vdso.bin
> [...]
> Entry point address: 0xffffffffff700700
> [...]
> Section Headers:
> [Nr] Name Type Address Off Size ES Flg Lk Inf Al
> [ 0] NULL 0000000000000000 000000 000000 00 0 0 0
> [ 1] .hash HASH ffffffffff700120 000120 000038 04 A 2 0 8
> [ 2] .dynsym DYNSYM ffffffffff700158 000158 0000d8 18 A 3 2 8
> [...]
> [ 9] .dynamic DYNAMIC ffffffffff700580 000580 0000f0 10 WA 3 0 8
Thanks,
Pedro Alves
next prev parent reply other threads:[~2014-09-21 19:12 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 16:25 Doug Evans
2014-09-11 16:37 ` Pedro Alves
2014-09-12 11:55 ` Jan Kratochvil
2014-09-12 12:14 ` Pedro Alves
2014-09-12 12:33 ` Jan Kratochvil
2014-09-12 12:46 ` Pedro Alves
2014-09-17 20:10 ` Jan Kratochvil
2014-09-19 14:38 ` Pedro Alves
2014-09-19 14:41 ` Pedro Alves
2014-09-20 21:30 ` Jan Kratochvil
2014-09-21 19:12 ` Pedro Alves [this message]
2014-09-21 19:46 ` Pedro Alves
2014-09-23 23:05 ` Doug Evans
2014-09-26 12:09 ` Pedro Alves
2014-09-22 18:35 ` Jan Kratochvil
2014-09-23 11:49 ` Pedro Alves
2014-09-28 13:41 ` Jan Kratochvil
2014-09-29 10:36 ` Pedro Alves
2014-10-03 13:09 ` Gary Benson
2014-10-07 23:16 ` Doug Evans
2014-09-23 12:05 ` Pedro Alves
2014-09-26 12:05 ` Pedro Alves
2014-09-23 10:59 ` automated testing comment [Re: time to workaround libc/13097 in fsf gdb?] Jan Kratochvil
2014-09-23 12:32 ` Pedro Alves
2014-09-23 12:45 ` Jan Kratochvil
2014-09-23 13:30 ` Pedro Alves
2014-09-23 13:57 ` Jan Kratochvil
2014-09-23 14:48 ` Pedro Alves
2014-09-23 15:53 ` Jan Kratochvil
2014-09-23 15:56 ` Pedro Alves
2014-09-24 13:22 ` Andreas Arnez
2014-09-24 15:23 ` Ulrich Weigand
2014-09-25 7:11 ` Andreas Arnez
2014-09-25 8:20 ` Pedro Alves
2014-09-25 10:52 ` Jan Kratochvil
2014-09-23 14:54 ` Doug Evans
2014-09-23 15:16 ` Simon Marchi
2014-09-23 14:48 ` Doug Evans
2014-09-23 14:59 ` Pedro Alves
2014-09-20 19:50 ` time to workaround libc/13097 in fsf gdb? Jan Kratochvil
2014-09-23 11:18 ` Pedro Alves
2014-09-23 13:16 ` Gary Benson
2014-10-09 20:09 ` Jan Kratochvil
2014-10-09 22:07 ` Pedro Alves
2014-09-13 1:06 ` Doug Evans
2014-09-17 20:13 ` Jan Kratochvil
2014-09-23 21:35 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=541F2311.1040404@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=xdje42@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox