[Dwarf-discuss] Re: dwarf2 question [abbreviations]

[David Anderson]

Michael Eager:
> There is no ordering specified in the spec, so I can't say that it
> is safe to assume that abbrevitions are in ascending order.  On the
> other hand, I believe most compilers write the abbrev section from
> a fixed list, which would (most likely) be in order.
> 
> The design of the abbrev section allows a compiler to dynamically
> generate abbreviations, which might not be in order.
> 
> Given that the abbrev table has variable length entries, most
> compilers would read the table into memory and create an index
> so that one could quickly find the desired abbrev entry.  That way
> the question of whether the entries are in order becomes moot.

Mathieu Lacage
|Yes, I am trying to write a parser which uses a minimum amount of memory
|but which is reasonably efficient.
|
|I guess I can assume they are in ascending order since at least the
|tables generated by gcc seem to be in ascending order and if I cannot
|find what I am looking for, I can easily revert to simply parsing the
|whole table. Of course, this will be probably less efficient if they are
|never in order but well...

As Michael points out within a single .o there is no ordering
requirement on the abbreviation tags
in the abbreviation table.  
Consequently you cannot depend on ordering.
(If the compilation system uses dwarf3-duplicate-eliminations
there can be multiple abbreviations (and other) sections in a single
.o).

But in practice I would think most compilation systems would
have abbreviation codes in sequential order most of the time.
For example, the libdwarf producer code generates
abbreviations in sequential order.


An executable or DSO (shared library) is built of multiple .o's
and might therefore contain multiple small abbreviations tables.
Leaving me uncertain what you mean by 'the whole table'.

Normally the number of abbreviations for a single .o is quite small.
And involves only very small abbreviation numbers.

If a compilation system were to somehow merge abbreviations tables
a single table might grow large, but  that's off the point I think.

You will need to fall back to allowing arbitrary order when
you find something out of order within a particular abbreviation table.

David Anderson [wondering what I am missing here...]