This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Dwarf2 FDE CIE offset
On Fri, Dec 07, 2001 at 03:38:56PM -0500, Daniel Jacobowitz wrote:
> On Fri, Dec 07, 2001 at 07:48:11PM +1030, Alan Modra wrote:
> > Why is the dwarf2 unwind FDE CIE offset calculated as
> > ". - section_start_label" while dwarf2 debug info uses
> > "section_start_label - 0"? In particular, why the sign change?
> >
> > I've been implementing section groups for gcc, with the aim of being able
> > to discard .eh_frame and .debug_frame info when garbage collecting an
> > unused function. This involves splitting the .eh_frame section into
> > multiple sections. The header stays in .eh_frame, and per function info
> > goes into .eh_frame0, .eh_frame1 etc.
> > eg.
>
> Have you considered doing this just by editing the eh_frame sections in
> the linker? Yes, I know it's ugly, but most of the machinery is there
> after my stabs work; and that should be the only entry in the unwind
> table whose value depends on the location within the .eh_frame section,
> so you'd just need to be careful to adjust symbols and relocs a little
> more correctly than I do for stabs.
Worse, you'd need to edit the eh_frame section in the linker, or make
the assembler emit relocs for those FDE CIE offsets. I don't
particularly like the idea of teaching the linker all about
debug/unwind formats. It's a too "clever" solution for my liking.
I much prefer simple, robust solutions. What happens when the
eh_frame format changes (again)?
> A comment was made about the
> problems with section proliferation when I suggested using separate
> .stabs sections, IIRC.
ELF gives us 64k sections per object file. If that's not enough, it
would be almost trivial to modify the linker to handle more, using
0xffff for shnum in the external program header to mean "lots", and
poke the real count somewhere.
Alan