Mail Archives: djgpp-workers/2003/05/22/13:54:25
This is a multi-part message in MIME format.
------=_NextPart_000_004F_01C3209B.784D7DF0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
> > > Since gcc 3.3 is being discussed anyway, could whoever acts
> > > as DJGPP maintainer for gcc (DJ I believe) take another look
> > > at gcc bug bootstrap/3867?
> >
> > The patch looks fundamentally OK. Could you please generate a fresh
> > patch for the 3.3 branch and the trunk, retest each, and repost? CC
> > me at dj AT redhat DOT com and I'll push it through.
>
> Tim,
>
> Could you send me a copy directly to me so that I can patch
> the GCC and
> test it allot before the next alpha release.
>
> Thanks,
> Andrew
The patch attached to the bug report applied cleanly to the configure.in
of gcc 3.3. I tested on Linux (worked correctly) and made a fresh diff
(cfr. attachment). I have not yet checked gcc CVS head.
One caveat - this test (both original & patched) may break if autoconf
> 2.13 is used to generate configure, as it may strip trailing
whitespace
(and the test relies on those to be preserved properly).
------=_NextPart_000_004F_01C3209B.784D7DF0
Content-Type: application/octet-stream;
name="eh_frame.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="eh_frame.patch"
Index: gcc/configure.in=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /cvsroot/gcc/gcc/gcc/configure.in,v=0A=
retrieving revision 1.627.2.8=0A=
diff -u -r1.627.2.8 configure.in=0A=
--- gcc/configure.in 12 May 2003 18:49:18 -0000 1.627.2.8=0A=
+++ gcc/configure.in 21 May 2003 07:26:29 -0000=0A=
@@ -1720,40 +1720,44 @@=0A=
as_ver=3D`$gcc_cv_as --version < /dev/null 2> /dev/null | head -1`=0A=
rm -f a.out 2> /dev/null=0A=
if echo "$as_ver" | grep GNU > /dev/null; then=0A=
+ # Try both .4byte and .long (COFF targets don't grok .4byte,=0A=
+ # and .long is not necessarily the same as .4byte for non-COFF=0A=
+ # targets)=0A=
+ for gcc_PSEUDO_OP in 4byte long; do=0A=
# Versions up to and including 2.11.0 may mis-optimize=0A=
# .eh_frame data. Try something.=0A=
cat > conftest.s <<EOF=0A=
.text=0A=
.LFB1:=0A=
- .4byte 0=0A=
+ .${gcc_PSEUDO_OP} 0=0A=
.L1:=0A=
- .4byte 0=0A=
+ .${gcc_PSEUDO_OP} 0=0A=
.LFE1:=0A=
- .section .eh_frame,"aw",@progbits=0A=
+ .section .eh_frame=0A=
__FRAME_BEGIN__:=0A=
- .4byte .LECIE1-.LSCIE1=0A=
+ .${gcc_PSEUDO_OP} .LECIE1-.LSCIE1=0A=
.LSCIE1:=0A=
- .4byte 0x0=0A=
- .byte 0x1=0A=
- .ascii "z\0"=0A=
- .byte 0x1=0A=
- .byte 0x78=0A=
- .byte 0x1a=0A=
- .byte 0x0=0A=
- .byte 0x4=0A=
- .4byte 1=0A=
- .p2align 1=0A=
+ .${gcc_PSEUDO_OP} 0x0=0A=
+ .byte 0x1=0A=
+ .ascii "z\0"=0A=
+ .byte 0x1=0A=
+ .byte 0x78=0A=
+ .byte 0x1a=0A=
+ .byte 0x0=0A=
+ .byte 0x4=0A=
+ .${gcc_PSEUDO_OP} 1=0A=
+ .p2align 1=0A=
.LECIE1:=0A=
.LSFDE1:=0A=
- .4byte .LEFDE1-.LASFDE1=0A=
+ .${gcc_PSEUDO_OP} .LEFDE1-.LASFDE1=0A=
.LASFDE1:=0A=
- .4byte .LASFDE1-__FRAME_BEGIN__=0A=
- .4byte .LFB1=0A=
- .4byte .LFE1-.LFB1=0A=
- .byte 0x4=0A=
- .4byte .LFE1-.LFB1=0A=
- .byte 0x4=0A=
- .4byte .L1-.LFB1=0A=
+ .${gcc_PSEUDO_OP} .LASFDE1-__FRAME_BEGIN__=0A=
+ .${gcc_PSEUDO_OP} .LFB1=0A=
+ .${gcc_PSEUDO_OP} .LFE1-.LFB1=0A=
+ .byte 0x4=0A=
+ .${gcc_PSEUDO_OP} .LFE1-.LFB1=0A=
+ .byte 0x4=0A=
+ .${gcc_PSEUDO_OP} .L1-.LFB1=0A=
.LEFDE1:=0A=
EOF=0A=
cat > conftest.lit <<EOF=0A=
@@ -1761,20 +1765,33 @@=0A=
0010 01000000 12000000 18000000 00000000 ................=0A=
0020 08000000 04080000 0044 .........D =0A=
EOF=0A=
+ cat > conftest.lit2 <<EOF=0A=
+ 0000 10000000 00000000 017a0001 781a0004 .........z..x...=0A=
+ 0010 01000000 12000000 18000000 00000000 ................=0A=
+ 0020 08000000 04080000 00440000 .........D.. =0A=
+EOF=0A=
cat > conftest.big <<EOF=0A=
0000 00000010 00000000 017a0001 781a0004 .........z..x...=0A=
0010 00000001 00000012 00000018 00000000 ................=0A=
0020 00000008 04000000 0844 .........D =0A=
EOF=0A=
+ cat > conftest.big2 <<EOF=0A=
+ 0000 00000010 00000000 017a0001 781a0004 .........z..x...=0A=
+ 0010 00000001 00000012 00000018 00000000 ................=0A=
+ 0020 00000008 04000000 08440000 .........D.. =0A=
+EOF=0A=
# If the assembler didn't choke, and we can objdump,=0A=
# and we got the correct data, then succeed.=0A=
if $gcc_cv_as -o conftest.o conftest.s > /dev/null 2>&1 \=0A=
&& $gcc_cv_objdump -s -j .eh_frame conftest.o 2>/dev/null \=0A=
| tail -3 > conftest.got \=0A=
- && { cmp conftest.lit conftest.got > /dev/null 2>&1 \=0A=
- || cmp conftest.big conftest.got > /dev/null 2>&1; }=0A=
+ && { cmp conftest.lit conftest.got > /dev/null 2>&1 \=0A=
+ || cmp conftest.big conftest.got > /dev/null 2>&1 \=0A=
+ || cmp conftest.lit2 conftest.got > /dev/null 2>&1 \=0A=
+ || cmp conftest.big2 conftest.got > /dev/null 2>&1; }=0A=
then=0A=
gcc_cv_as_eh_frame=3D"yes"=0A=
+ break=0A=
else=0A=
gcc_cv_as_eh_frame=3D"bad"=0A=
if $gcc_cv_as -o conftest.o --traditional-format /dev/null; then=0A=
@@ -1782,6 +1799,7 @@=0A=
[Define if your assembler mis-optimizes .eh_frame data.])=0A=
fi=0A=
fi=0A=
+ done=0A=
fi=0A=
rm -f conftest.*=0A=
fi=0A=
------=_NextPart_000_004F_01C3209B.784D7DF0--
- Raw text -