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