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: Roland McGrath <roland at hack dot frob dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Tue, 29 Jan 2013 14:36:13 -0800
- Subject: Re: [patch] Fix 64-bit->32-bit vDSO reporting
> As long we permit first a_val to be zero there is probably no solution.
Agreed (though disappointed, since you are usually so much more clever than
I am! ;-).
> 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).
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).
> I do not find opening /proc/PID/exe such a performance loss but it is true
> I have chosen elfutils for its performance so it is not fair to make it worse.
Understood it's a lot of microoptimization in a context where it's probably
swamped by many other things. But I am certainly happier if there is at
least the likely possibility of not adding any syscalls.
> Implemented trying to decode it both ways each time, it is IMO zero-cost
> as it is only more userland computations without involving more syscalls.
Agreed.
> If it gets ambiguous it will fallback to /proc/PID/exe; but that should
> never happen.
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.
Thanks,
Roland