This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] validate binary before use
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Aleksandar Ristovski <aristovski at qnx dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 4 Apr 2013 10:13:02 +0200
- Subject: Re: [patch] validate binary before use
- References: <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> <515CDF7F dot 5020403 at qnx dot com>
On Thu, 04 Apr 2013 04:03:43 +0200, Aleksandar Ristovski wrote:
> 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.
Why?
If the target shared library does not match then GDB will read some random
memory. The target shared library may not even have any build-id.
As the build-id has 160 bits there is 1:2^160 probability of a false positive,
that is safe enough.
> The chunk of code that is in svr4_relocate_section_addresses in the
you probably mean solib_map_sections
> latest version of the patch needs to go back to svr4_validate, and
> not store build-id.
I do not understand this whole mail, it would be best to provide a countercase
where the current patchset does not behave correctly.
Thanks,
Jan