GCC Bugzilla – Bug 3867
[djgpp] eh_frame optimization check in configure is broken
Last modified: 2006-01-21 03:06:41 UTC
The test for bad eh_frame optimization emits an assembler file intended as input for gas. Unfortunately, this uses directives that are not supported by all targets of gas. In particular, it uses .4byte, and .section 'foo',blah which are supported by ELF targets, but not by i386 coff targets (such as DJGPP's coff-go32). Replacing the .4byte with .long and dropping the excess parameters from .section allows gas to process the file. objdump -s -j .eh_frame on the result yields: x.o: file format coff-go32 Contents of section .eh_frame: 0010 10000000 00000000 017a0001 781a0004 .........z..x... 0020 01000000 12000000 18000000 00000000 ................ 0030 08000000 04080000 00440000 .........D.. Which is identical to the conftest.lit used in the test, aside from the two extra zero bytes at the end (which I assume to be an alignment issue - which is also not taken into account by the test). This leads to a (presumably) false negatice on this platform. Release: gcc cvs (gcc-3_0-branch) Environment: Platform: i386-pc-msdosdjgpp How-To-Repeat: configure gcc for a DJGPP target (presumably many other non-ELF targets are affected)
Fix: Change the assembler source to use more portable directives, test for specific error messages from gas, or use the output from a trivial C++ compile instead: echo 'int main(void) { return 0; }' >foo.cc gcc -S foo.cc as foo.s -o foo.o objdump -s -j .eh_frame foo.o
State-Changed-From-To: open->feedback State-Changed-Why: This is a rather old bootstrap failure report, and gcc3.0 is no longer supported. Can you please check whether you can build a newer version of gcc on your platform and let us know about your findings? Thanks W.
State-Changed-From-To: feedback->analyzed State-Changed-Why: Problem still exists. You seem to understand the reason quite well. Would you mind preparing a patch for this and submitting it to gcc-patches@gcc.gnu.org? Thanks W.
From: Tim Van Holder <tim.van.holder@pandora.be> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: bootstrap/3867: [djgpp] eh_frame optimization check in configure is broken Date: 21 Nov 2002 08:58:15 +0100 It's not a failure as such - configure merely finds the eh_frame optimization bug when it is not present. This is still the case in gcc 3.2; configure.in contains a piece of assembler code that uses .4byte and multiple arguments for .section. Even when binutils 2.13 is used, those are NOT supported for coff targets (djgpp, mingw32), causing as to fail, and configure to assume the test failed. Using .long instead of .4byte and removing the extra arguments to .section results in an assembler file that gives the proper results for coff as well as ELF. The check for the linker's eh_frame header optimization is even more broken for those platforms, as it checks 4- and 8-byte alignments (using .${gc_WS}byte as pseudo-op); in that test it is not possible to simply replace .4byte by .long. Perhaps this is a binutils issue (perhaps as should treat .4byte as a synonym for .long for a COFF target, and silently ignore extra arguments for .section), but this has been causing gcc to misdetect eh_frame stuff on COFF platforms for quite a while now. -- Tim Van Holder <tim.van.holder@pandora.be>
From: Tim Van Holder <tim.van.holder@pandora.be> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, gcc-patches@gnu.org Cc: Subject: Re: bootstrap/3867: [djgpp] eh_frame optimization check in configure is broken Date: 22 Nov 2002 11:21:45 +0100 --=-S4jqjPL03BtO75628iE7 Content-Type: text/plain Content-Transfer-Encoding: 7bit http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3867 Patch (well, more of a hack) is attached. However, I do not know whether .long and .4byte are necessarily equivalent (I suspect they won't be on 64-bit hosts), so I left in checks for both .4byte and .long. Also, I left out the ,"aw",@progbits args for .section, and I'm not sure that this won't affect the tests on some platforms (it doesn't on Linux, but that's the only non-COFF platform I have access to). Additionally, I'm not entirely sure that checking for lit2 and big2 is valid (for all I know the extra padding is exactly the failure being detected). Someone with exact knowledge of the issue being checked here will need to verify it. In any case, this patch causes configure to consider mingw32, using binutils 2.13, a non-broken platform when it comes to assembler eh_frame optimizations. Note: the use of .4byte in the linker test is safe, as it is only run if the linker supports PT_GNU_EH_FRAME, and that is currently only the case if the linker supports elf. -- Tim Van Holder <tim.van.holder@pandora.be> --=-S4jqjPL03BtO75628iE7 Content-Disposition: attachment; filename=eh_frame.patch Content-Type: text/plain; name=eh_frame.patch; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit --- configure.orig 2002-11-22 10:04:46.000000000 +0100 +++ configure.in 2002-11-22 10:52:39.000000000 +0100 @@ -1628,40 +1628,44 @@ as_ver=`$gcc_cv_as --version < /dev/null 2> /dev/null | head -1` rm -f a.out 2> /dev/null if echo "$as_ver" | grep GNU > /dev/null; then + # Try both .4byte and .long (COFF targets don't grok .4byte, + # and .long is not necessarily the same as .4byte for non-COFF + # targets) + for gcc_PSEUDO_OP in 4byte long; do # Versions up to and including 2.11.0 may mis-optimize # .eh_frame data. Try something. cat > conftest.s <<EOF .text .LFB1: - .4byte 0 + .${gcc_PSEUDO_OP} 0 .L1: - .4byte 0 + .${gcc_PSEUDO_OP} 0 .LFE1: - .section .eh_frame,"aw",@progbits + .section .eh_frame __FRAME_BEGIN__: - .4byte .LECIE1-.LSCIE1 + .${gcc_PSEUDO_OP} .LECIE1-.LSCIE1 .LSCIE1: - .4byte 0x0 - .byte 0x1 - .ascii "z\0" - .byte 0x1 - .byte 0x78 - .byte 0x1a - .byte 0x0 - .byte 0x4 - .4byte 1 - .p2align 1 + .${gcc_PSEUDO_OP} 0x0 + .byte 0x1 + .ascii "z\0" + .byte 0x1 + .byte 0x78 + .byte 0x1a + .byte 0x0 + .byte 0x4 + .${gcc_PSEUDO_OP} 1 + .p2align 1 .LECIE1: .LSFDE1: - .4byte .LEFDE1-.LASFDE1 + .${gcc_PSEUDO_OP} .LEFDE1-.LASFDE1 .LASFDE1: - .4byte .LASFDE1-__FRAME_BEGIN__ - .4byte .LFB1 - .4byte .LFE1-.LFB1 - .byte 0x4 - .4byte .LFE1-.LFB1 - .byte 0x4 - .4byte .L1-.LFB1 + .${gcc_PSEUDO_OP} .LASFDE1-__FRAME_BEGIN__ + .${gcc_PSEUDO_OP} .LFB1 + .${gcc_PSEUDO_OP} .LFE1-.LFB1 + .byte 0x4 + .${gcc_PSEUDO_OP} .LFE1-.LFB1 + .byte 0x4 + .${gcc_PSEUDO_OP} .L1-.LFB1 .LEFDE1: EOF cat > conftest.lit <<EOF @@ -1669,20 +1673,33 @@ 0010 01000000 12000000 18000000 00000000 ................ 0020 08000000 04080000 0044 .........D EOF + cat > conftest.lit2 <<EOF + 0000 10000000 00000000 017a0001 781a0004 .........z..x... + 0010 01000000 12000000 18000000 00000000 ................ + 0020 08000000 04080000 00440000 .........D.. +EOF cat > conftest.big <<EOF 0000 00000010 00000000 017a0001 781a0004 .........z..x... 0010 00000001 00000012 00000018 00000000 ................ 0020 00000008 04000000 0844 .........D EOF + cat > conftest.big2 <<EOF + 0000 00000010 00000000 017a0001 781a0004 .........z..x... + 0010 00000001 00000012 00000018 00000000 ................ + 0020 00000008 04000000 08440000 .........D.. +EOF # If the assembler didn't choke, and we can objdump, # and we got the correct data, then succeed. if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 \ && $gcc_cv_objdump -s -j .eh_frame conftest.o 2>/dev/null \ | tail -3 > conftest.got \ - && { cmp conftest.lit conftest.got > /dev/null 2>&1 \ - || cmp conftest.big conftest.got > /dev/null 2>&1; } + && { cmp conftest.lit conftest.got > /dev/null 2>&1 \ + || cmp conftest.big conftest.got > /dev/null 2>&1 \ + || cmp conftest.lit2 conftest.got > /dev/null 2>&1 \ + || cmp conftest.big2 conftest.got > /dev/null 2>&1; } then gcc_cv_as_eh_frame="yes" + break else gcc_cv_as_eh_frame="bad" if $gcc_cv_as -o conftest.o --traditional-format /dev/null; then @@ -1690,6 +1707,7 @@ [Define if your assembler mis-optimizes .eh_frame data.]) fi fi + done fi rm -f conftest.* fi --=-S4jqjPL03BtO75628iE7--
From: Dara Hazeghi <dhazeghi@yahoo.com> To: tim.van.holder@pandora.be, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: bootstrap/3867: [djgpp] eh_frame optimization check in configure is broken Date: Wed, 14 May 2003 01:24:28 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=3867 Hi Tim, you sent a patch to address this issue to gcc-patches quite a while back. What's the status? Was it ever applied? Thanks, Dara
From: "Tim Van Holder" <tim.van.holder@pandora.be> To: "'Dara Hazeghi'" <dhazeghi@yahoo.com>, <gcc-gnats@gcc.gnu.org>, <nobody@gcc.gnu.org> Cc: Subject: Re: bootstrap/3867: [djgpp] eh_frame optimization check in configure is broken Date: Wed, 14 May 2003 15:30:59 +0200 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=g cc&pr=3867 > > Hi Tim, > > you sent a patch to address this issue to gcc-patches quite a while > back. What's the status? Was it ever applied? Thanks, > > Dara I haven't heard much about this, and the gcc 3.2.3 tree still uses elf-centric assembler code (.4byte etc), so I assume this is still a problem (unless gas was changed to handle those opcodes for coff targets).
patch here: <http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01361.html>
DJ, do you have any suggestions for this problem? Is the patch referenced sufficient? Is djgpp sufficiently buildable on current gcc that such a patch would make much of a difference? Thanks.
Subject: Re: [djgpp] eh_frame optimization check in configure is broken The patch seems sufficient, but I still need to test and review it. I only recently got my DJGPP build working again (re the -imacros bugs). I just need to find time to go through the DJGPP backlog.
DJ, any chance you might be able to have a look at this soon? Thanks.
Subject: Re: [djgpp] eh_frame optimization check in configure is broken > DJ, any chance you might be able to have a look at this soon? Thanks. The code in configure.in (er, configure.ac) changed so I adapted the patch by simply adding a second whole test. Tested with a linux-x-djgpp cross and a linux native. Alex, this look OK to you? 2004-01-19 DJ Delorie <dj@redhat.com> * configure.ac (gcc_cv_as_eh_frame2): New, check non-elf systems also and override gcc_cv_as_eh_frame. * configure: Regenerate. Index: configure.ac =================================================================== RCS file: /cvs/gcc/gcc/gcc/configure.ac,v retrieving revision 2.8 diff -p -2 -r2.8 configure.ac *** configure.ac 19 Jan 2004 16:57:04 -0000 2.8 --- configure.ac 20 Jan 2004 01:38:34 -0000 *************** EOF *** 2021,2024 **** --- 2021,2091 ---- fi]) + if test $gcc_cv_as_eh_frame != yes; then + # Also check for non-ELF syntax + gcc_GAS_CHECK_FEATURE(non-elf eh_frame optimization, gcc_cv_as_eh_frame2, + [2,12,0],, + [ .text + .LFB1: + .long 0 + .L1: + .long 0 + .LFE1: + .section .eh_frame + __FRAME_BEGIN__: + .long .LECIE1-.LSCIE1 + .LSCIE1: + .long 0x0 + .byte 0x1 + .ascii "z\0" + .byte 0x1 + .byte 0x78 + .byte 0x1a + .byte 0x0 + .byte 0x4 + .long 1 + .p2align 1 + .LECIE1: + .LSFDE1: + .long .LEFDE1-.LASFDE1 + .LASFDE1: + .long .LASFDE1-__FRAME_BEGIN__ + .long .LFB1 + .long .LFE1-.LFB1 + .byte 0x4 + .long .LFE1-.LFB1 + .byte 0x4 + .long .L1-.LFB1 + .LEFDE1:], + [ dnl # For autoconf 2.5x, must protect trailing spaces with @&t@. + cat > conftest.lit <<EOF + 0000 10000000 00000000 017a0001 781a0004 .........z..x... + 0010 01000000 12000000 18000000 00000000 ................ + 0020 08000000 04080000 00440000 .........D.. @&t@ + EOF + cat > conftest.big <<EOF + 0000 00000010 00000000 017a0001 781a0004 .........z..x... + 0010 00000001 00000012 00000018 00000000 ................ + 0020 00000008 04000000 08440000 .........D.. @&t@ + EOF + # If the assembler didn't choke, and we can objdump, + # and we got the correct data, then succeed. + if test x$gcc_cv_objdump != x \ + && $gcc_cv_objdump -s -j .eh_frame conftest.o 2>/dev/null \ + | tail -3 > conftest.got \ + && { cmp conftest.lit conftest.got > /dev/null 2>&1 \ + || cmp conftest.big conftest.got > /dev/null 2>&1; } + then + gcc_cv_as_eh_frame=yes + gcc_cv_as_eh_frame2=yes + elif AC_TRY_COMMAND($gcc_cv_as -o conftest.o --traditional-format /dev/null); then + gcc_cv_as_eh_frame=buggy + gcc_cv_as_eh_frame2=buggy + else + # Uh oh, what do we do now? + gcc_cv_as_eh_frame=no + gcc_cv_as_eh_frame2=no + fi]) + fi + if test $gcc_cv_as_eh_frame = buggy; then AC_DEFINE(USE_AS_TRADITIONAL_FORMAT, 1,
Subject: Re: [djgpp] eh_frame optimization check in configure is broken On Jan 19, 2004, DJ Delorie <dj@redhat.com> wrote: > Alex, this look OK to you? I can't spot any problems. > 2004-01-19 DJ Delorie <dj@redhat.com> > * configure.ac (gcc_cv_as_eh_frame2): New, check non-elf > systems also and override gcc_cv_as_eh_frame. > * configure: Regenerate.
DJ, I can't see that this patch was ever applied? If it's still good, might be nice to finally wrap this issue up :-)