This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DWARF2 unwinding documentation/help
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 03 Sep 2003 12:54:07 +0200
- Subject: Re: DWARF2 unwinding documentation/help
- Organization: Develer S.r.l.
- References: <200308241753.28678.bernie@develer.com> <20030825213203.GB19623@redhat.com>
Richard Henderson wrote:
(sorry for the long delay, I'm just back from vacation).
On Sun, Aug 24, 2003 at 05:53:28PM +0200, Bernardo Innocenti wrote:
My target is an m68k-elf variant using a surrogate of the ELF format.
At what point are you surrogating? At the .s level, .o level,
or at final link? Depending on the nature of the true target
format, waiting until final link to produce the not-ELF format
may be easiest.
Binaries are pre/post-processed at the final link stage. The linker
is replaced by a shell script invoking the real linker with additional
flags and an "elf2flt" program to convert the result to a flat binary.
The fake linker also keeps the original elf file (with a .gdb extension)
for debugging pourposes.
It needs to place the unwinding tables in the data segment and doesn't
link crtbegin/crtend. I've seen EH related stuff in there, but I'm
not sure whether they are needed.
Again, depending on the above. But if you can't wait until
final link (when you can just fold .eh_frame into .data),
then this should be as simple as (1) not providing named
sections, or (2) defining EH_FRAME_IN_DATA_SECTION.
EH_FRAME_IN_DATA_SECTION is already defined in my target.
Something bad is happening during the first unwinding phase.
Perhaps it has to do with the missing register_frame_info()
as Jim Wilson pointed out, or it's something else.
Also suspicious is that the m68k back-end handling of
DWARF2 information for function prologues/epilogues is quite
different from other back-ends (I've looked in i386 and arm).
While the generation is a bit different, because of the way we
currently print prologues as text, the result should be very
similar to x86.
Ok. One less thing to worry about. Does the dwarf2 output depend
on frame size and layout? Does the unwinder need to know where
registers are being saved on the stack?
With ELF object files, study the output of readelf -wf and -wF
together with the dwarf2 docs and you should achieve Enlightenment.
I will as soon as I'm done replying all remaining mail in the queue.
Thank you very much for your help!
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html