> 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 _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
