This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need for an additional flag


Michael Matz <matz@suse.de> writes:

> Basically I want to annotate the .debug_str section with hashes for all
> the contained string.  My gcc currently emits something like this in the
> .debug_str section:
> 
>         .section        .debug_str,"MS",@progbits,1
>         .long   110593184
>         .byte   0
> .LC161:
>         .string "_G_int32_t"
>         .long   55641640
>         .byte   0
> .LC168:
>         .string "_sbuf"
> 
> I.e. the (32bit) hash value is prepended to the string.  The tools are
> fine with this layout, but to make use of those hashes I actually have to
> differ between .debug_str which do, and those which don't contain the
> hash values.  For now I added a "H" flag, and a SHF_HASH ELF flag which
> maps to SEC_ROM which then is, what I test in merge.c to avoid computing
> the hash value for each string, which is actually the biggest bottleneck
> in ld right now.

Perhaps you could simply start the section with a magic code of some
sort, and look for that instead of for SHF_HASH_ELF.  A four byte code
which has two zero bytes in a row would, I think, never be generated
by other tools.  Something like 0xfe0000ef might work.

Adding an SHF_HASH_ELF flag is likely to conflict with somebody else's
work, unless you coordinate through the ELF maintainers.
Unfortunately I think that may currently be SCO.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]