[patch] validate binary before use
Aleksandar Ristovski
aristovski@qnx.com
Fri Feb 1 21:32:00 GMT 2013
On 13-02-01 03:04 PM, Jan Kratochvil wrote:
> On Fri, 01 Feb 2013 15:31:27 +0100, Aleksandar Ristovski wrote:
>> On 13-01-31 10:06 PM, Jan Kratochvil wrote:
>>> This behavior is correct. Changing it would break all the tools around.
>>
>> <offtopic>
>> If you say so. IMO it is less than ideal, it should specify l_addr
>> as expected and make prelink transparent. Like this, it special
>> cases meaning of this field, which is common and across many systems
>> happens to always have the same meaning (except when 'successful'
>> prelinking happens).
>> </offtopic>
>
> FYI on gdbserver/linux-low.c get_phdr_phnum_from_proc_auxv finds PHDR_MEMADDR
> which is the absolute L_ADDR form you ask for.
>
> Just solib-svr4.c tries to be (is it?) cross-OS compatible so it does not have
> this PHDR_MEMADDR value available.
<still-offtopic>
To avoid any misunderstanding: I am not emotional about this topic at
all. Take what follows as a light-weight hallway conversation over a coffee:
I will not claim familiarity with how linux works, but auxv typically
has information for the executable only, not the shared objects (i.e.
auxv is the "connecting link" between process loader and dynamic linker
- interpreter). For shared objects, however, this can not be used
because the information is not there. Dynamic linker does not add
anything to auxv nor does auxv have entries for e.g. load base of any of
the shared objects.
To be clear: I am very familiar with how this works on Neutrino and the
preceding and following claims come from that and *not* from gnu/ld
familiarity. If it's different on gnu/linux, let me know.
Using auxv is fairly os-agnostic as long as an os is svr4-like.
solib-svr4.c uses auxv via target_auxv_search, nothing wrong with that.
But again, this applies to exe only. Auxv does not have any information
about arbitrary shared objects executable links against - that is
entirely ld's business and not process loader's.
Therefore, the only clue for deterministic and straight forward
relocation calculus for a tool like gdb is l_addr from the link map. If
gnu ld is not setting it up when "successful prelink" happens it is
making a mistake: 0 load base may be legitimate and true in some cases
on some systems. Furhter, it unnecessary introduces this difference when
it would probably change very little (nothing?) if it set it up
correctly to what the load base really is, just as it does for
"unsuccessful" prelinks or non-prelinked objects.
</still-offtopic>
More information about the Gdb-patches
mailing list