Re: [PATCH v4 0/8] Validate binary before use

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Sun, 09 Mar 2014 20:18:55 +0100, Eli Zaretskii wrote:
> > "Shared object" is terminology in GDB, it is in fact the symbol file because
> > GDB never modifies the inferior itself where the real target shared object
> > exists.
> > 
> > Just with the build-id comparisons I used "shared library" (as the target
> > in-memory data) vs. "symbol file" to highlight this difference.
> 
> Sorry, I don't follow: libfoo.so.1 is a shared library, isn't it?
> There's no reference in the message to any symbol file, right?

target in-memory data:
  Found by iterating memory structures like link_map.
  Name like "libfoo.so.1" is found in link_map->l_name in target memory.
symbol file:
  Found on host disk, from transforming the target name "libfoo.so.1"
  (such as by adding "set sysroot" prefix).

These two files do not have to match.  This patch ensures that if they do not
match then the second file is not loaded.

I do not think there is currently any established term for the first file
so it is questionable how to communicate the non-matching situation to user.


> > > and doesn't even mention the fact that the problem is a mismatch of the
> > > 2 build-ids.  Why not say explicitly that the build-id of the symbol file
> > > doesn't match that of the shared library?
> > 
> > This comes from the API, I can rework the patch.  The API currently uses
> > method "validate" which can validate it in arbitary way.  The current only
> > implmentation in solib-svr4 implements the validation using build-ids but the
> > error/warning message is currently handled by the caller, not the
> > build-id-specific implementation in solib-svr4.
> 
> I think it's fine to leave the validation details unspecified, if you
> want.  But then we shouldn't reveal that its actual implementation is
> comparing the build-ids.  If we want to leave it opaque, let's do it
> consistently, i.e. both in the warnings printed by GDB and in the
> manual.  OTOH, if we do want to tell that build-ids should be
> identical, then let's say that in the warning/error messages as well,
> again for consistency.

I have changed the code to print the build IDs instead.


Thanks,
Jan