This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] validate binary before use
- From: Aleksandar Ristovski <aristovski at qnx dot com>
- To: gdb-patches at sourceware dot org
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 03 Apr 2013 22:03:43 -0400
- Subject: Re: [patch] validate binary before use
- References: <5107F591 dot 304 at qnx dot com> <20130131063518 dot GA3027 at host2 dot jankratochvil dot net> <510A7EB0 dot 90702 at qnx dot com> <51278A2A dot 9000802 at qnx dot com> <512E42D1 dot 3040101 at qnx dot com> <514C58B2 dot 6090701 at qnx dot com> <20130328183727 dot GA14798 at host2 dot jankratochvil dot net> <515B0632 dot 1040502 at qnx dot com> <20130402165306 dot GA9479 at host2 dot jankratochvil dot net> <515B12D1 dot 7050505 at qnx dot com> <20130403180917 dot GA6102 at host2 dot jankratochvil dot net>
Actually, as I think about this more, we can not use section from
possibly unrelated bfd to read build-id in native debugging case. At a
minimum, we can not store such build-id as abfd may not even relate to
what's in target's memory.
The chunk of code that is in svr4_relocate_section_addresses in the
latest version of the patch needs to go back to svr4_validate, and not
store build-id.
Ideally, however, build id would be read from target memory phdrs, not
from bfd.
Main complication, of course, is that due to missing load base for a
shared object, this becomes target os specific. On Neutrino, it is
straight forward, but on gnu it requires parsing smaps.
So, I'm thinking that linux-nat should be taught to return
TARGET_OBJECT_LIBRARIES_SVR4, and also augument gdbserver to return load
base.
i.e. gdbserver would return, in addition to what it already does, a
mandatory attribute "load_base".
If a native implementation does not support
TARGET_OBJECT_LIBRARIES_SVR4, build-id is not checked.
Thoughts?