This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Indexed string tables?
On Wed, Dec 8, 2010 at 2:05 AM, Ian Lance Taylor <iant@google.com> wrote:
> I would say that the string tables in bfd/hash.c are sequentially
> indexed. ?The hash table is there so that duplicate strings are only
> entered once. ?What do you want to do for duplicate strings? ?Enter them
> into the string table more than once?
Yes, OMF string tables are more like lists than like sets. I don't
think OMF has anything in principle against duplicate strings - it's
the ID that counts.
In broad strokes OMF works like this (by way of example):
Record that announces strings that get used in later records:
1 "TEXT"
2 "BSS"
3 "TEXT"
4 "DATA"
5 "" (sentinel)
(blah blah)
SEGDEF
1 ALLOC | EXEC
SEGDEF
2 ALLOC | BSS
SEGDEF
3 ALLOC | EXEC
As you can see string 3 appears multiple times; I needed to be able to
add strings to the string table regardless of whether it was already
present or not. Now that I look at the code in hash.c, I remember why
I had to roll my own: OMF wants a sequential index, not a byte index.
And I need to be able to look them up again by that ID. I don't see
_bfd_stringtab_add and friends supporting that easily, so I didn't
want to shoehorn my requirements into what really wants to be a
byte-offset-based or hash table.
The difference between the example above and what, say, ELF does is
that where an ELF section definition refers to a name (by byte offset
- this is minor) as a singleton, OMF's SEGDEF refers to a
non-singleton onject that just happens to have a name as its only
explicit attribute. But it's object identity that matters here, not
the object value - EQ? versus EQV? or EQUAL? in scheme-ese.
I hope I've explained it clearly enough. It's late and it's been a
long time since I worked on this port!