Re: [PATCH v5 7/8] Validate symbol file using build-id

Jan Kratochvil
2014-03-21T16:58:35Z

On Thu, 20 Mar 2014 14:13:06 +0100, Aleksandar Ristovski wrote:
> On 14-03-19 06:31 PM, Jan Kratochvil wrote:
> >+@smallexample
> >+ warning: Shared object "libfoo.so.1" could not be validated (remote
> >+ build ID 2bc1745e does not match local build ID a08f8767) and will be
>
> I am not sure 'remote' adds any clarity here, on-contrary, I think
> it will confuse. This could all be happening in local scenario as
> well. The gist should be: inferior so build-id (i.e. build-id of the
> shared object loaded in the inferior memory) does not match build-id
> of the so gdb loaded to get symbols.

Therefore:
s/remote/inferior/
s/local/symbol file/

------------------------------------------------------------------------------
@smallexample
warning: Shared object "libfoo.so.1" could not be validated (inferior
build ID 2bc1745e does not match symbol file build ID a08f8767) and
will be ignored; or use 'set solib-build-id-force'.
@end smallexample

Turning on this setting would load such symbol file while still printing:

@smallexample
warning: Shared object "libfoo.so.1" could not be validated (inferior
build ID 2bc1745e is not identical to symbol file build ID a08f8767)
but it is being loaded due to 'set solib-build-id-force'.
@end smallexample
------------------------------------------------------------------------------

> >+If remote build-id is present but it does not match local build-id (or local
> >+build-id is not present) then this setting enables (@var{mode} is @code{on}) or
> >+disables (@var{mode} is @code{off}) loading of such symbol file. On systems
> >+where build-id is not present in the remote system this setting has no effect.
> >+The default value is @code{off}.
>
> and here. I think 'inferior' would be a lot more suitable reference
> than "remote system".

Done.

Thanks,
Jan