Elf Header sh_addr field not according to spec

[Mike_Sorensen at arium dot com]

I am analyzing ELF headers for several different compilers including gcc 2.9
and 3.0.  I have noticed a difference between what the ELF spec states
should be in the sh_addr field of a section header and what happens to be
there in gcc generated code.

Specifically, in the .debug_info section header, the spec states that the
sh_addr field should be zero as this section is not allocated memory (its
allocation bit is not set).  In gcc 2.9, I noticed that the address field
actually contains a memory offset that I have found useful to calculate the
precise location of a .debug_abbrev segment from its compilation_unit's
abbrev-offset.

For example in gcc 2.9 generated code, a compilation unit header's abbrev
offset appears to be a memory offset that I have been converting to a file
offset with the use of this sh_addr field.  I use this sh_addr field to
determine the factor to convert memory offsets to file offsets.  I can go
from the compilation_unit's abbrev-offset field (a memory offset) to the
.debug_abbrev section for that compilation_unit which requires a file offset
to find.

This works eventhough it is not precisely out of the ELF spec I have read.

The big problem I've been hit with is when I try to use the same routines to
analyze gcc 3.0 generated code.  In the case of gcc 3.0, the sh_addr field
of the .debug_abbrev section header does not contain a memory offset that
helps me find the abbrev segment for a compilation unit.  The compilation
unit's header contains sufficient information to locate its abbrev segment.
This is fine, but now my code needs to know if I'm looking at gcc 2.9 or gcc
3.0 generated code before I can get to the abbrev segment (and fully
understand the .debug_info sections).

If it makes a difference, my gcc 3.0 code is for IA64 and most of my efforts
previously have been for gcc 2.9 on x86 (32-bit addresses).

I hope my problem statement is not too confusing...  ;^)

Is there someone out there that can tell me why there is a number in the ELF
section header for the .debug_abbrev section and why it is important in gcc
2.9 and unimportant in gcc 3.0?

Mike Sorensen