Re: [RFC] Wrong register numbers in .dwarf_frame on Linux/PowerPC

[Mark Wielaard <mjw at redhat dot com>]

On Mon, 2012-11-26 at 20:10 +0100, Ulrich Weigand wrote:
> I noticed what appears to be a long-standing bug in generating .dwarf_frame
> sections with GCC on Linux on PowerPC.
> 
> It had been my understanding that .dwarf_frame is supposed to differ from
> .eh_frame on PowerPC w.r.t. register numbers: .eh_frame should use GCC
> internal numbers, while .dwarf_frame should use the DWARF register numbers
> documented in the PowerPC ELF ABI.  However, in actual fact, .dwarf_frame
> does not use the DWARF numbers; and it does not use the GCC numbers either,
> but a weird mixture: it uses GCC numbers for everything except for the
> condition code register, for which it uses the DWARF number (64).
> [...]
> Unfortunately, "use a newer version of
> GCC" isn't really quite right any more: the only versions of GCC that
> ever did it correctly were 4.0 and 4.1, it would appear.

Aha. Thanks for the investigation. I remember being very confused when
hacking on the Systemtap unwinder for ppc64. This explains it (RHEL5
derived distributions use GCC 4.1, but most others use something much
older or much newer).

> So I'm wondering where to go from here.  I guess we could:
> 
> 1. Bring GCC (and gas) behaviour in compliance with the documented ABI
>    by removing the #undef DBX_REGISTER_NUMBER and changing gas's
>    md_reg_eh_frame_to_debug_frame to the original implementation from
>    Jakub's patch.  That would make GDB work well on new files, but
>    there are a large number of binaries out there where we continue
>    to have the same behaviour as today ...
> 
> 2. Leave GCC and gas as-is and modify GDB to expect GCC numbering in
>    .dwarf_frame, except for the condition code register.  This would
>    break debugging of files built with GCC 4.0 and 4.1 unless we
>    want to add a special hack for that.
> 
> 3. Like 2., but remove the condition code hack: simply use identical
>    numbers in .eh_frame and .dwarf_frame.  This would make PowerPC
>    like other Linux platforms in that respect.
> 
> Thoughts?

Which other unwinders are out there, that might rely on the current
numbering? The Systemtap runtime unwinder (*) currently is incomplete
(and in one case wrong since the numbering overlaps), so it doesn't
really matter much which solution you pick (we will just have to watch
out and fix things to be as consistent as possible when your change goes
through). If you do change the numbering it would be ideal if there was
a way to detect which one was in place (although it is probably hopeless
because depending on which GCC version is in use there can already be
different numberings). BTW. The reason the systemtap runtime unwinder is
a little wrong here is because on all other architectures we assume
eh_frame and debug_frame DWARF register numberings are equal, is ppc
really the only architecture for which that isn't true, or were we just
lucky?

Thanks,

Mark

(*) The Systemtap runtime unwinder has this comment that explains (or
maybe confuses things even more...):

/* These are slightly strange since they don't really use dwarf register
   mappings, but gcc internal register numbers. There is some confusion about
   the numbering see http://gcc.gnu.org/ml/gcc/2004-01/msg00025.html
   We just handle the 32 fixed point registers, mq, count and link and
   ignore status registers, floating point, vectors and special registers
   (most of which aren't available in pt_regs anyway). Also we placed nip
   last since we use that as UNW_PC register and it needs to be filled in.
   Note that we handle both the .eh_frame and .debug_frame numbering at
   the same time. There is potential overlap though. 64 maps to cr in one
   and mq in the other...
   Everything else is mapped to an invalid register number 9999. */