This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [patch] Fix 64-bit->32-bit vDSO reporting
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 30 Jan 2013 21:08:28 +0100
- Subject: Re: [patch] Fix 64-bit->32-bit vDSO reporting
On Tue, 29 Jan 2013 23:36:13 +0100, Roland McGrath wrote:
> > We could detect it also from the format of /proc/PID/maps, for 64-bit
> > inferiors there will always be some of the modules at >= 4GB.
> > But that also nobody guarantees.
>
> There is no guarantee at all (though in practice for x86-64 you are
> guaranteed to see the [vsyscall] fake entry with its fixed high address).
Besides other issues I find this detection to be at a lower level than to
expect some OS-specific segment there.
> And it's much more roundabout than looking at the ELF header of
> /proc/PID/exe and not better in any other way (same minimal number of
> syscalls required).
This grovel_auxv only caller already reads /proc/PID/maps anyway so the
[vsyscall] would theoretically help in the improbable
case of valid32 && valid64.
> Agreed, though my pedanticism insists that we have that fallback and my
> paranoia that you at least fiddle the code temporarily to ensure you have
> tested the /proc/PID/exe code path.
Yes.
Thanks,
Jan