Rebased to master e96bd93d436e464a532a7e1161e1d201c9fc50c7

The problems I listed below are not addressed, this is simply rebased.



On 13-04-04 09:03 AM, Aleksandar Ristovski wrote:
> On 13-04-04 04:13 AM, Jan Kratochvil wrote:
>> 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 problem is, we could 'remember' build-id that is garbage. I will add
> checking for GNU\0 and note type, and then the likelihood that somewhat
> random memory will match namesz, name and type will be very low (though
> the likelihood has nothing to do with the 160 bits of build-id; build-id
> is not necessarily 160 bits either).
>
> The rest of the e-mail applies:
>
>>
>>
>>> 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.
>
>
> The above should explain why is current patchset incorrect (in
> particular patch #7).
>
> The rest is about design and duplicated functionality. The functionality
> of gdbserver where it fetches the list is exactly the same what -nat can
> do; in fact this could be the same code; and then solib-svr4.c deals
> only with TARGET_OBJECT_LIBRARIES_SVR4. The infrastructure is in place.
>
> Impact on solib-svr4.c: svr4_validate would be exactly as it is now,
> simply check. svr4_relocate_section_addresses would not need the kludge
> for reading build-id, there would be only one path of getting build-id.
>
> Not to be neglected is that by doing so, it would be possible to look
> for the debug binary directly, by using build-id instead of opening
> objfile and then looking for separate_debug_fie.
>
>
> ---
> Aleksandar
>
>