Re: Mixing 32-bit and 64-bit DWARF2/3 sections

David Anderson
2004-11-09T21:54:49Z

James E Wilson <wilson@specifixinc.com> writes:
|SGI Irix6 created the N64 ABI, and they decreed that one must use a
|(non-standard) 64-bit DWARF format with it. We are just following the
|ABI here. If we change it, then we lose compatibility with Irix6, and
|the published ABI.

There was no standard 64 bit dwarf format at the time (1992,3,4).
A straight '64 bit address-size and offset' was simple to define
and understand.

|> P.S. It seems that MIPS is the only 64-bit target for which this is a
|> problem, since all other 64-bit targets (AMD64, UltraSPARC) still
|> use the 32-bit DWARF format.

|This is because SGI decided that DWARF2 was broken, and tried to fix it
|by adding 64-bit extensions. These extensions are only needed if you
|have more than 4GB of DWARF debug info, and hence is unlikely, but SGI
|claims that they did hit this limit. No one else has apparently ever
|hit the limit.

Allow me to correct that impression. I don't know that anyone
has exceeded a 4GB dwarf section. Nor did we think DWARF2 was
broken, exactly. Knowing that the issue of gigantic debug
files was simply never on the table at the DWARF committee
meetings, (there being no need at that point in time), we made
a guess as to what a future DWARFx would have. Bad guess.
The DWARF committee was either exhausted or dormant (depending
on the date) by this time, so no further changes could
be contemplated there.

This was 1992 or so.

It was clear from past experience was that *someone would*
exceed 32 bits of offset. And when it happened, the
restriction was going to seem arbitrary and would be painful to
correct.

Every limit in mdebug had been hit by that time, and being
unable to correct those problems was...painful. We'd only felt
able to correct an mdebug limit once (back around 1989) and
that binary incompatibility was --- painful to deal with. (In
that case MIPS [as a separate company] broke the ABI to fix an
mdebug limit and we went along as that was the only real
choice.)

|Unfortunately, the way that SGI extended DWARF2 caused problems, as it
|resulted in ambiguous DWARF info, so the DWARF3 committee defined a
|different way that is self descriptive. But since this happened after
|Irix6 had already been released, and SGI could not break backwards
|compatibility with Irix6, N64 still uses the non-standard 64-bit DWARF
|format that SGI invented. And gcc uses this non-standard 64-bit DWARF
|format for all mips64 targets, for consistency, and to conform with the ABI.

At the time there was only one 64bit MIPS, and no 64bit offset DWARF.
[And no other 64-bit ELF users? (I vaguely recall.). No
other DWARF2 users at that time.]
We at SGI felt obliged to do something to avoid the limits in 32bit
offset DWARF2. Our choice did not really meet the needs and desires of
today's community thus DWARF3 has a different approach to 64bit offsets.

Daniel Berlin <dberlin@dberlin.org> writes:
[...]
|In short, there is no limitation in dwarf3 that SGI is solving.
|It's just a matter of them not solving it in a backwards compatible way,
|and everyone else paying the consequences :)

Well, we associate dwarf-offset with elf-offset.
So 64-bit-elf-offset means 64-bit-dwarf offset.
It seemed perfectly compatible then.
Our solution was for a limitation in DWARF2, and only DWARF2 existed
at the time.

Jim Wilson again:
>I don't think we should be worried about use of 32-bit DWARF2 debug
>info. We are unlikely to hit the limits anytime soon. And if we do hit
>the limits, then we will likely have other more serious problems.

The limits will be hit, likely before long.
The problems will be seen only in a tiny subset of applications.
Since 13TB ram-memory machines exist today, a 5GB .debug_info
does not seem that large. Admittedly such a size is likely avoidable
by using shared-libraries.

On IRIX the only appropriate 64-bit DWARF2 is
the IRIX definition. Beyond that I'm not going...

David Anderson
[PS: Opinions my own, not those of SGI. History is as I recall what
happened at the time.]