DWARF2_FRAME_REG_OUT

I noticed that Geoff Keating's old hack of...

+#define DBX_REGISTER_NUMBER(n) \
+ (TARGET_64BIT ? dbx64_register_map[n] \
+ : write_symbols == DWARF2_DEBUG ? svr4_dbx_register_map[n] \
+ : dbx_register_map[n])

Hi Jack.

I have no idea what this random hunk of gcc code does, but target specific dwarf register numbers are handled by the backend, not the frontend. If you're seeing a specific bug, it is best to file it.

-Chris

Hi Jack,

is still present in config/i386/darwin.h for llvm-gcc42, but I can't find an analogous code in clang.
Does clang handle this issue differently than llvm-gcc42?

No, clang handle this issue exactly the same way as llvm-gcc. The
answer is simple: this part of code is for gcc backend, which is not
used by llvm code at all.
LLVM backend can have the arbitrary list of register numbers. Right
now they are (on x86): "for 64 bit", "for 32 bit debug", "for 32 bit
eh".

Hi Chris,

I have no idea what this random hunk of gcc code does, but target specific dwarf register numbers are handled by the backend, not the frontend. If you're seeing a specific bug, it is best to file it.

There is one specific place, where llvm-gcc uses some bits of the gcc
backend. This is the lowering of dwarf_reg_sizes gcc builtin -
basically the result is an array indexed by a dwarf register number
and containing the size of the corresponding registers. llvm-gcc
handles the lowering in a hacky way: it initializes gcc backend and
queries for register sizes. Though, given the mapping, it doesn't
matter whether the hack is applied or not :slight_smile:

Hi Jack,

> is still present in config/i386/darwin.h for llvm-gcc42, but I can't find an analogous code in clang.
> Does clang handle this issue differently than llvm-gcc42?
No, clang handle this issue exactly the same way as llvm-gcc. The
answer is simple: this part of code is for gcc backend, which is not
used by llvm code at all.
LLVM backend can have the arbitrary list of register numbers. Right
now they are (on x86): "for 64 bit", "for 32 bit debug", "for 32 bit
eh".

Anton,
   My understanding is that DWARF2_FRAME_REG_OUT existed on darwin
because the register 4 (EBP) and register 5 (ESP) got swapped long ago
and that macro existed because the eh_frame register numbering and the
DWARF debug info registering numbering were different for those two.
Was this issue FSF gcc specific or in the standards themselves?
                  Jack

Jack,

My understanding is that DWARF2_FRAME_REG_OUT existed on darwin
because the register 4 (EBP) and register 5 (ESP) got swapped long ago
and that macro existed because the eh_frame register numbering and the
DWARF debug info registering numbering were different for those two.
Was this issue FSF gcc specific or in the standards themselves?

The register numbering is platform-specific, so it's neither fsf gcc
nor standard specific.
We just emitting debug/eh info with different register numbers for
different platforms.