Re: .eh_frame problem

[Ian Lance Taylor <ian@cygnus.com>]

   From: "Mark E." <snowball3@usa.net>
   Date: Wed, 3 Mar 1999 00:56:54 -0500

   Could somebody from binutils read the thread archived at 
   http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00547.html . It's 
   a thread about a padding problem with .eh_frame and at least DJGPP. 
   According to the egcs folks, this problem needs to be solved in gas. 
   Are they right?

I think it would be more reliable to fix this in gcc, but it could
also be fixed in gas.  The basic problem is that gas doesn't know
whether a section contains code or not.  Thus it has to guess about
how to align the contents of the section.

   I forgot to mention DJGPP (i[34567]-pc-msdosdjgpp) uses COFF.
   I wonder if .eh_frame should be given flagged like a data section (like 
   .edata and others are) in sec_to_stype_flags and in 
   style_to_sec_flags. Then wouldn't .eh_frame be padded with 0x0 
   instead of 0x90 (NOP) as it currently is?

I doubt it, since I think that djgpp doesn't use BFD_ASSEMBLER.  If
you look at gas/config/tc-i386.h at md_maybe_text, you will see how
gas guesses whether to pad with 0x90 or 0.

What does egcs say in the .section directive for .eh_frame for djgpp?
Is there enough information there for the assembler to somehow know
that the section contains data rather than code?  If there is, then we
should figure out how to get that information to md_maybe_text, as
should already work for the BFD_ASSEMBLER version of gas.

Ian