This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Need for an additional flag
- From: Michael Matz <matz at suse dot de>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 19 Sep 2003 17:43:17 +0200 (CEST)
- Subject: Re: Need for an additional flag
Hi,
On 19 Sep 2003, Ian Lance Taylor wrote:
> It depends upon what it does. There isn't a correct generic answer.
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.
I choose this way, because adding another section holding the hashes would
just be much more complicated, and adding some bytes between strings in
.debug_str is okay in the sense that it's just more padding (in
record_section() those "pad" bytes are taken as strings and entered into
the hash table in non-SHF_HASH aware bfd, but that's just a minor
inconvenience).
Ciao,
Michael.