From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: snowball3@usa.net Cc: gas2@cygnus.com Subject: Re: .eh_frame problem Date: Wed, 03 Mar 1999 16:53:00 -0000 Message-id: <199903040053.QAA03202@rtl.cygnus.com> References: <199903030556.FAA07970@out5.ibm.net> X-SW-Source: 1999/msg00028.html From: "Mark E." 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