Re: RPATH/RUNPATH issue, equivalent to -headerpad on OSX

["Gavin Beatty" <gavinbeatty at gmail dot com>]

Hello,

I'm trying to ready a patch for submission about this issue. I would
add an -rpath-pad option taking the number of bytes to pad the
RPATH/RUNPATH.

The path of least resistance to add such a capability seems to me to
be to move from using const char* C strings as hash values and to use
char* mem, unsigned int len pairs instead. For almost all current code
using bfd, the only change would be passing an extra argument with the
value strlen(str). The default api could even remain and the strlen
call be made before calling the generic version.

E.g.,

/* Look up a string in a hash table.  */
struct bfd_hash_entry *
bfd_hash_lookup (struct bfd_hash_table *table,
         const char *string,
         bfd_boolean create,
         bfd_boolean copy)
{
  bfd_hash_lookup_generic(table, string, strlen(string), create, copy);
}

/* Look up a string in a hash table. Can lookup non-C strings also.
Useful for padding etc. */
struct bfd_hash_entry *
bfd_hash_lookup (struct bfd_hash_table *table,
         char *string,
         unsigned int len,
         bfd_boolean create,
         bfd_boolean copy)
{
    /* slight alteration of current code (memcpy in a few places) */
}

Any harsh responses to this approach? There wouldn't need to be any
special handling of the padded NULLs as strcmp("/some/path",
"/some/path\0\0\0") == 0. Maybe warn in the docs for anyone trying to
add "some awful str\0\0ing that will be wrecked" entries?

TBH I'm not at all intimate with binutils code and would like some
guidance wrt this.


Cheers,
Gavin

-- 
Gavin Beatty

SEMPER UBI SUB UBI