This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Need for an additional flag
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: binutils at sources dot redhat dot com
- Date: 19 Sep 2003 19:58:33 -0700
- Subject: Re: Need for an additional flag
- References: <Pine.LNX.4.44.0309191733550.12065-100000@wotan.suse.de>
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