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


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.


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