Branching for 2.12

Branching for 2.12

[Daniel Jacobowitz]

Nothing big's broken lately.  And most of what I was waiting for has gone
in.  So, while there are a few things left that I want fixed before release
(most notably to me is the problem I posted with stdbool.h conflicting with
bfd.h; I'll try to finish the patch tomorrow), I think we're mostly there.

I ask that no one commit anything large and non-urgent for about a week. 
Then, on Tuesday (February 5th), I plan to create the branch for 2.12. 
We'll let it sit for some time, probably two to three weeks, picking up only
critical patches; spin a snapshot for testing; and hopefully release in
about six weeks.

Any objections?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Branching for 2.12

[Christopher Faylor]

On Tue, Jan 29, 2002 at 02:03:57AM -0500, Daniel Jacobowitz wrote:
>Nothing big's broken lately.  And most of what I was waiting for has gone
>in.  So, while there are a few things left that I want fixed before release
>(most notably to me is the problem I posted with stdbool.h conflicting with
>bfd.h; I'll try to finish the patch tomorrow), I think we're mostly there.

Actually, I hate to do this, but I haven't been able to build a working
cross-build environment for Windows for a couple of weeks.  ld is SEGVing.

I'd hoped that DJ Delorie's recent change might solve the problem but it
doesn't.  ld is dying reading stabs information.

I don't have a lot of time to track this down but if a working Windows
version of binutils is a requirement for a new release, then I think
we've got a problem.

cgf

Re: Branching for 2.12

[Daniel Jacobowitz]

On Tue, Jan 29, 2002 at 10:54:19AM -0500, Christopher Faylor wrote:
> On Tue, Jan 29, 2002 at 02:03:57AM -0500, Daniel Jacobowitz wrote:
> >Nothing big's broken lately.  And most of what I was waiting for has gone
> >in.  So, while there are a few things left that I want fixed before release
> >(most notably to me is the problem I posted with stdbool.h conflicting with
> >bfd.h; I'll try to finish the patch tomorrow), I think we're mostly there.
> 
> Actually, I hate to do this, but I haven't been able to build a working
> cross-build environment for Windows for a couple of weeks.  ld is SEGVing.
> 
> I'd hoped that DJ Delorie's recent change might solve the problem but it
> doesn't.  ld is dying reading stabs information.
> 
> I don't have a lot of time to track this down but if a working Windows
> version of binutils is a requirement for a new release, then I think
> we've got a problem.

Blargh.

Windows host or target?  And cygwin rather than mingw2 I assume?  I'll
look at it if you can give me a testcase and a config.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Branching for 2.12

[Christopher Faylor]

On Tue, Jan 29, 2002 at 10:56:52AM -0500, Daniel Jacobowitz wrote:
>On Tue, Jan 29, 2002 at 10:54:19AM -0500, Christopher Faylor wrote:
>> On Tue, Jan 29, 2002 at 02:03:57AM -0500, Daniel Jacobowitz wrote:
>> >Nothing big's broken lately.  And most of what I was waiting for has gone
>> >in.  So, while there are a few things left that I want fixed before release
>> >(most notably to me is the problem I posted with stdbool.h conflicting with
>> >bfd.h; I'll try to finish the patch tomorrow), I think we're mostly there.
>> 
>> Actually, I hate to do this, but I haven't been able to build a working
>> cross-build environment for Windows for a couple of weeks.  ld is SEGVing.
>> 
>> I'd hoped that DJ Delorie's recent change might solve the problem but it
>> doesn't.  ld is dying reading stabs information.
>> 
>> I don't have a lot of time to track this down but if a working Windows
>> version of binutils is a requirement for a new release, then I think
>> we've got a problem.
>
>Blargh.
>
>Windows host or target?  And cygwin rather than mingw2 I assume?  I'll
>look at it if you can give me a testcase and a config.

Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
If you build a cross compiler and try to link gdb, ld will fail, or
at least it does for me.

cgf

Re: Branching for 2.12

[Alexandre Oliva]

On Jan 29, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> Any objections?

No objection on creating the branch.  Just so that I don't forget to
report again, I've been having trouble with a native gcc+binutils+gdb
build on AIX 4.1 for a couple of weeks.  I'm about to start this
week's GCC snapshot build (along with the other tool-chain tools) and,
if I'm lucky, I may have time to look into the problem.

I don't recall the exact problem any longer, but one of the tools
failed to use an archive created by another of the tools, claiming it
was not a proper archive.  Quite odd.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Branching for 2.12

[Daniel Jacobowitz]

On Tue, Jan 29, 2002 at 10:41:06PM -0200, Alexandre Oliva wrote:
> On Jan 29, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> 
> > Any objections?
> 
> No objection on creating the branch.  Just so that I don't forget to
> report again, I've been having trouble with a native gcc+binutils+gdb
> build on AIX 4.1 for a couple of weeks.  I'm about to start this
> week's GCC snapshot build (along with the other tool-chain tools) and,
> if I'm lucky, I may have time to look into the problem.
> 
> I don't recall the exact problem any longer, but one of the tools
> failed to use an archive created by another of the tools, claiming it
> was not a proper archive.  Quite odd.

This usually involves corruption in ranlib (or the use of a ranlib
targeted at the wrong configuration).  Interesting...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Branching for 2.12

[Alexandre Oliva]

On Jan 30, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:

> On Tue, Jan 29, 2002 at 10:41:06PM -0200, Alexandre Oliva wrote:

>> No objection on creating the branch.  Just so that I don't forget to
>> report again, I've been having trouble with a native gcc+binutils+gdb
>> build on AIX 4.1 for a couple of weeks.  I'm about to start this
>> week's GCC snapshot build (along with the other tool-chain tools) and,
>> if I'm lucky, I may have time to look into the problem.

> This usually involves corruption in ranlib (or the use of a ranlib
> targeted at the wrong configuration).  Interesting...

Here's the exact failure mode.

stage1/xgcc -Bstage1/ -B/home/lsd/oliva/test/egcs/unknown-AIX-1/powerpc-ibm-aix4.1.5.0/bin/ -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H -DGENERATOR_FILE  -o gengenrtl \
 gengenrtl.o ../libiberty/libiberty.a
collect2: stage1/libgcc.a: not a COFF file

Interestingly, `ar t' from binutils 2.11 shows the archive members
just fine, but that from CVS mainline gives:

BFD: BFD 2.11.93 20020129 assertion fail /home/lsd/oliva/src/tool/egcs/bfd/libbfd.c:1110

before proceeding to list all archive members correctly.

I'll try to look further into it tomorrow.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

AIX 4.1 broken (was: Re: Branching for 2.12)

[Alexandre Oliva]

On Jan 30, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> collect2: stage1/libgcc.a: not a COFF file

> Interestingly, `ar t' from binutils 2.11 shows the archive members
> just fine, but that from CVS mainline gives:

> BFD: BFD 2.11.93 20020129 assertion fail /home/lsd/oliva/src/tool/egcs/bfd/libbfd.c:1110

> before proceeding to list all archive members correctly.

> I'll try to look further into it tomorrow.

The reason it fails is that _bfd_xcoff_slurp_armap() calls H_GET_64(),
but this macro calls bfd_getb64() that BFD_FAIL()s ifndef BFD64.  AIX
4.1 is not a 64-bit architecture, so it's reasonable that BFD64 is not
defined, but where is the error: should _bfd_xcoff_slurp_armap() be
fixed so as to not call H_GET_64() ifndef BFD64 or should bfd_getb64
do its job regardless of the macro?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Alan Modra]

On Wed, Jan 30, 2002 at 09:36:19PM -0200, Alexandre Oliva wrote:
> On Jan 30, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
> 
> > collect2: stage1/libgcc.a: not a COFF file
> 
> > Interestingly, `ar t' from binutils 2.11 shows the archive members
> > just fine, but that from CVS mainline gives:
> 
> > BFD: BFD 2.11.93 20020129 assertion fail /home/lsd/oliva/src/tool/egcs/bfd/libbfd.c:1110
> 
> > before proceeding to list all archive members correctly.
> 
> > I'll try to look further into it tomorrow.
> 
> The reason it fails is that _bfd_xcoff_slurp_armap() calls H_GET_64(),
> but this macro calls bfd_getb64() that BFD_FAIL()s ifndef BFD64.  AIX
> 4.1 is not a 64-bit architecture, so it's reasonable that BFD64 is not
> defined, but where is the error: should _bfd_xcoff_slurp_armap() be
> fixed so as to not call H_GET_64() ifndef BFD64 or should bfd_getb64
> do its job regardless of the macro?

If BFD64 is not defined, then bfd_vma (which is an unsigned long in this
case) may not be large enough to return a 64 bit value from bfd_getb64.
In fact, handling of 64 bit values throughout bfd may be broken.

For that reason, I think _bfd_xcoff_slurp_armap should not try to handle
64 bit archives when BFD64 is undefined.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

PATCH, Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Tom Rix]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

This is problem I caused by making the big archive format <bigaf> the default.

The included patch enables the old behavior of creating new archives with the small archive
format <aiaff> for pre AIX 4.3.

I do not have ready access to an AIX 4.1 box so it has not been tested natively.   I did test
it on a cross built binutils.   I did see the assertion errors.   This patch cleared them
up.   Sanity check on magic #'s seems ok.

I will run this through AIX 4.3.3 tomorrow.

Could someone with an AIX 4.1 box please validate this patch for that target?

Thanks
Tom

Alexandre Oliva wrote:

> On Jan 30, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
>
> > collect2: stage1/libgcc.a: not a COFF file
>
> > Interestingly, `ar t' from binutils 2.11 shows the archive members
> > just fine, but that from CVS mainline gives:
>
> > BFD: BFD 2.11.93 20020129 assertion fail /home/lsd/oliva/src/tool/egcs/bfd/libbfd.c:1110
>
> > before proceeding to list all archive members correctly.
>
> > I'll try to look further into it tomorrow.
>
> The reason it fails is that _bfd_xcoff_slurp_armap() calls H_GET_64(),
> but this macro calls bfd_getb64() that BFD_FAIL()s ifndef BFD64.  AIX
> 4.1 is not a 64-bit architecture, so it's reasonable that BFD64 is not
> defined, but where is the error: should _bfd_xcoff_slurp_armap() be
> fixed so as to not call H_GET_64() ifndef BFD64 or should bfd_getb64
> do its job regardless of the macro?
>
> --
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist                Professional serial bug killer

--
Tom Rix
GCC Engineer
trix@redhat.com



[-- Attachment #2: aiaff-001fa.patch --]
[-- Type: text/plain, Size: 2368 bytes --]

2002-01-31  Tom Rix  <trix@redhat.com>

	* config.bfd: Conditionally support <aiaff> for pre AIX 4.3.

	* xcoff.h: Conditionally support <aiaff> for pre AIX 4.3.

diff -rcp src-old/bfd/config.bfd src/bfd/config.bfd
*** src-old/bfd/config.bfd	Wed Jan 30 22:32:46 2002
--- src/bfd/config.bfd	Wed Jan 30 23:08:57 2002
*************** case "${targ}" in
*** 780,785 ****
--- 780,788 ----
      case "${targ}" in
        *-*-aix4.[3456789]* | *-*-aix[56789]*)
  	want64=true;;
+ 	
+ 	*)
+ 	targ_cflags=-DSMALL_ARCHIVE;;
      esac
      ;;
  #ifdef BFD64

diff -rcp src-old/include/coff/xcoff.h src/include/coff/xcoff.h
*** src-old/include/coff/xcoff.h	Wed Jan 30 22:32:52 2002
--- src/include/coff/xcoff.h	Thu Jan 31 00:40:44 2002
*************** struct xcoff_ar_hdr_big
*** 606,623 ****
     `hdr' member has the same size and position in both formats.  
     <bigaf> is the default format, return true even when xcoff_ardata is 
     NULL. */
  #define xcoff_big_format_p(abfd) \
    ((NULL != bfd_ardata (abfd) && NULL == xcoff_ardata (abfd)) || \
     ((NULL != bfd_ardata (abfd)) && \
      (NULL != xcoff_ardata (abfd)) && \
      (xcoff_ardata (abfd)->magic[1] == 'b')))
! 
! /* For testing old format * /
! #undef xcoff_big_format_p
  #define xcoff_big_format_p(abfd) \
    (((NULL != bfd_ardata (abfd)) && \
      (NULL != xcoff_ardata (abfd)) && \
!     (xcoff_ardata (abfd)->magic[1] == 'b'))) / **/
  
  /* We store a copy of the xcoff_ar_file_hdr in the tdata field of the
     artdata structure.  Similar for the big archive.  */
--- 606,625 ----
     `hdr' member has the same size and position in both formats.  
     <bigaf> is the default format, return true even when xcoff_ardata is 
     NULL. */
+ #ifndef SMALL_ARCHIVE
+ /* Creates big archives by default */
  #define xcoff_big_format_p(abfd) \
    ((NULL != bfd_ardata (abfd) && NULL == xcoff_ardata (abfd)) || \
     ((NULL != bfd_ardata (abfd)) && \
      (NULL != xcoff_ardata (abfd)) && \
      (xcoff_ardata (abfd)->magic[1] == 'b')))
! #else
! /* Creates small archives by default. */
  #define xcoff_big_format_p(abfd) \
    (((NULL != bfd_ardata (abfd)) && \
      (NULL != xcoff_ardata (abfd)) && \
!     (xcoff_ardata (abfd)->magic[1] == 'b')))
! #endif
  
  /* We store a copy of the xcoff_ar_file_hdr in the tdata field of the
     artdata structure.  Similar for the big archive.  */

Re: PATCH, Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Alexandre Oliva]

On Jan 31, 2002, Tom Rix <trix@redhat.com> wrote:

> Could someone with an AIX 4.1 box please validate this patch for that target?

Thanks, I'm starting a bootstrap right now, and going to bed.  When I
wake up, it should already be past the point in which it failed, and
I'll report back.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Branching for 2.12

[Daniel Jacobowitz]

On Tue, Jan 29, 2002 at 10:59:30AM -0500, Christopher Faylor wrote:
> On Tue, Jan 29, 2002 at 10:56:52AM -0500, Daniel Jacobowitz wrote:
> >On Tue, Jan 29, 2002 at 10:54:19AM -0500, Christopher Faylor wrote:
> >> On Tue, Jan 29, 2002 at 02:03:57AM -0500, Daniel Jacobowitz wrote:
> >> >Nothing big's broken lately.  And most of what I was waiting for has gone
> >> >in.  So, while there are a few things left that I want fixed before release
> >> >(most notably to me is the problem I posted with stdbool.h conflicting with
> >> >bfd.h; I'll try to finish the patch tomorrow), I think we're mostly there.
> >> 
> >> Actually, I hate to do this, but I haven't been able to build a working
> >> cross-build environment for Windows for a couple of weeks.  ld is SEGVing.
> >> 
> >> I'd hoped that DJ Delorie's recent change might solve the problem but it
> >> doesn't.  ld is dying reading stabs information.
> >> 
> >> I don't have a lot of time to track this down but if a working Windows
> >> version of binutils is a requirement for a new release, then I think
> >> we've got a problem.
> >
> >Blargh.
> >
> >Windows host or target?  And cygwin rather than mingw2 I assume?  I'll
> >look at it if you can give me a testcase and a config.
> 
> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
> If you build a cross compiler and try to link gdb, ld will fail, or
> at least it does for me.

Could you please try to reproduce this, and give me more exact
instructions on how to make it bomb?

drow@nevyn:/opt/src/cygwin/obj-nat% file gdb/gdb.exe 
gdb/gdb.exe: MS Windows PE Intel 80386 console executable not relocatable

GCC head, binutils/gdb head, -g -O2.  Several megs worth of .stab
section.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH, Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Alexandre Oliva]

On Jan 31, 2002, Tom Rix <trix@redhat.com> wrote:

> This is problem I caused by making the big archive format <bigaf>
> the default.  The included patch enables the old behavior of
> creating new archives with the small archive format <aiaff> for pre
> AIX 4.3.

> I do not have ready access to an AIX 4.1 box so it has not been
> tested natively.

Thanks, my bootstrap is already in the middle of building stage2 of
GCC, so it's past the original point of failure, so it seems that the
problem was indeed fixed.  Thanks for the quick response!

> 2002-01-31  Tom Rix  <trix@redhat.com>

> 	* config.bfd: Conditionally support <aiaff> for pre AIX 4.3.

> 	* xcoff.h: Conditionally support <aiaff> for pre AIX 4.3.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Branching for 2.12

[Christopher Faylor]

On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
>On Tue, Jan 29, 2002 at 10:59:30AM -0500, Christopher Faylor wrote:
>> On Tue, Jan 29, 2002 at 10:56:52AM -0500, Daniel Jacobowitz wrote:
>> >On Tue, Jan 29, 2002 at 10:54:19AM -0500, Christopher Faylor wrote:
>> >> On Tue, Jan 29, 2002 at 02:03:57AM -0500, Daniel Jacobowitz wrote:
>> >> >Nothing big's broken lately.  And most of what I was waiting for has gone
>> >> >in.  So, while there are a few things left that I want fixed before release
>> >> >(most notably to me is the problem I posted with stdbool.h conflicting with
>> >> >bfd.h; I'll try to finish the patch tomorrow), I think we're mostly there.
>> >> 
>> >> Actually, I hate to do this, but I haven't been able to build a working
>> >> cross-build environment for Windows for a couple of weeks.  ld is SEGVing.
>> >> 
>> >> I'd hoped that DJ Delorie's recent change might solve the problem but it
>> >> doesn't.  ld is dying reading stabs information.
>> >> 
>> >> I don't have a lot of time to track this down but if a working Windows
>> >> version of binutils is a requirement for a new release, then I think
>> >> we've got a problem.
>> >
>> >Blargh.
>> >
>> >Windows host or target?  And cygwin rather than mingw2 I assume?  I'll
>> >look at it if you can give me a testcase and a config.
>> 
>> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
>> If you build a cross compiler and try to link gdb, ld will fail, or
>> at least it does for me.
>
>Could you please try to reproduce this, and give me more exact
>instructions on how to make it bomb?

Um.  Those were adequate instructions for making it bomb "for me".

I'll rebuild a current CVS and see if it is fixed now.

cgf

Re: PATCH, Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Ian Lance Taylor]

Tom Rix <trix@redhat.com> writes:

> + 	*)
> + 	targ_cflags=-DSMALL_ARCHIVE;;

Pretty much all uses of targ_cflags are actually host/target
confusion, and this one is no exception.  The choice of target should
not set host compilation flags.  If you want to create one type of
archive on AIX 4.1 and a different type of archive on AIX 4.3, then
you should have different target vectors.

Ian

Re: PATCH, Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Tom Rix]

Ian Lance Taylor wrote:

> Tom Rix <trix@redhat.com> writes:
>
> > +     *)
> > +     targ_cflags=-DSMALL_ARCHIVE;;
>
> Pretty much all uses of targ_cflags are actually host/target
> confusion, and this one is no exception.  The choice of target should
> not set host compilation flags.  If you want to create one type of
> archive on AIX 4.1 and a different type of archive on AIX 4.3, then
> you should have different target vectors.
>

In principle,  I agree with you.   But creating a new vector should be
done correctly.  It should be tested on an AIX 4.1 box.   If someone is
willing to give me a 4.1 box,  I will do the work.

Tom

--
Tom Rix
GCC Engineer
trix@redhat.com

Re: PATCH, Re: AIX 4.1 broken (was: Re: Branching for 2.12)

[Alexandre Oliva]

On Feb  2, 2002, Tom Rix <trix@redhat.com> wrote:

> In principle,  I agree with you.   But creating a new vector should be
> done correctly.  It should be tested on an AIX 4.1 box.   If someone is
> willing to give me a 4.1 box,  I will do the work.

I can't grant you access to the AIX 4.1 box I've got access to, but I
volunteer to test any patches you might come up with.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: Branching for 2.12

[Christopher Faylor]

On Thu, Jan 31, 2002 at 03:43:14PM -0500, Christopher Faylor wrote:
>On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
>>> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
>>> If you build a cross compiler and try to link gdb, ld will fail, or
>>> at least it does for me.
>>
>>Could you please try to reproduce this, and give me more exact
>>instructions on how to make it bomb?
>
>Um.  Those were adequate instructions for making it bomb "for me".
>
>I'll rebuild a current CVS and see if it is fixed now.

Ok, I've rebuilt and confirmed that a link of gdb.exe now works.

Attempting to rebuild the Cygwin DLL (winsup/cygwin) or any C++
utilities in winsup/utils seems to fail.

So, it looks like a c++ issue, maybe?  I rebuilt the entire toolchain
with a very recent gcc + binutils + ld + gas and the link step failed.
If I attempt to do the final link with an older toolchain, it works
fine.

So, it seems like ld or maybe collect2 (?) is the culprit?

cgf

Re: Branching for 2.12

[Daniel Jacobowitz]

On Tue, Feb 05, 2002 at 12:19:28AM -0500, Christopher Faylor wrote:
> On Thu, Jan 31, 2002 at 03:43:14PM -0500, Christopher Faylor wrote:
> >On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
> >>> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
> >>> If you build a cross compiler and try to link gdb, ld will fail, or
> >>> at least it does for me.
> >>
> >>Could you please try to reproduce this, and give me more exact
> >>instructions on how to make it bomb?
> >
> >Um.  Those were adequate instructions for making it bomb "for me".
> >
> >I'll rebuild a current CVS and see if it is fixed now.
> 
> Ok, I've rebuilt and confirmed that a link of gdb.exe now works.
> 
> Attempting to rebuild the Cygwin DLL (winsup/cygwin) or any C++
> utilities in winsup/utils seems to fail.
> 
> So, it looks like a c++ issue, maybe?  I rebuilt the entire toolchain
> with a very recent gcc + binutils + ld + gas and the link step failed.
> If I attempt to do the final link with an older toolchain, it works
> fine.
> 
> So, it seems like ld or maybe collect2 (?) is the culprit?

Maybe I'm just dense.  I did a clean build, from a partially-combined
tree of CVS head GCC and binutils.  I built newlib, winsup, and all the
utils (cygcheck.exe etc.).  They all linked using the cygwin-targetted
assembler and self-built cygwin DLLs.

Sorry, but to continue any further I need more information.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

cygwin issues with 2.12 (was Re: Branching for 2.12)

[Christopher Faylor]

On Fri, Feb 08, 2002 at 01:37:44AM -0500, Daniel Jacobowitz wrote:
>On Tue, Feb 05, 2002 at 12:19:28AM -0500, Christopher Faylor wrote:
>> On Thu, Jan 31, 2002 at 03:43:14PM -0500, Christopher Faylor wrote:
>> >On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
>> >>> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
>> >>> If you build a cross compiler and try to link gdb, ld will fail, or
>> >>> at least it does for me.
>> >>
>> >>Could you please try to reproduce this, and give me more exact
>> >>instructions on how to make it bomb?
>> >
>> >Um.  Those were adequate instructions for making it bomb "for me".
>> >
>> >I'll rebuild a current CVS and see if it is fixed now.
>> 
>> Ok, I've rebuilt and confirmed that a link of gdb.exe now works.
>> 
>> Attempting to rebuild the Cygwin DLL (winsup/cygwin) or any C++
>> utilities in winsup/utils seems to fail.
>> 
>> So, it looks like a c++ issue, maybe?  I rebuilt the entire toolchain
>> with a very recent gcc + binutils + ld + gas and the link step failed.
>> If I attempt to do the final link with an older toolchain, it works
>> fine.
>> 
>> So, it seems like ld or maybe collect2 (?) is the culprit?
>
>Maybe I'm just dense.  I did a clean build, from a partially-combined
>tree of CVS head GCC and binutils.  I built newlib, winsup, and all the
>utils (cygcheck.exe etc.).  They all linked using the cygwin-targetted
>assembler and self-built cygwin DLLs.
>
>Sorry, but to continue any further I need more information.

I don't have any to offer, unfortunately.  can.  Perhaps you could be
more specific about what information you require?

Do you want me to send you object files?  Stub libraries?

Just to be clear, I'm doing this all on linux.  Your mention of DLLs
makes me think that you are possibly doing this on Windows although
that's probably just a terminology problem since you don't normally use
DLLs in linking.

cgf

Re: cygwin issues with 2.12 (was Re: Branching for 2.12)

[Christopher Faylor]

On Sat, Feb 09, 2002 at 08:47:41PM -0500, Christopher Faylor wrote:
>On Fri, Feb 08, 2002 at 01:37:44AM -0500, Daniel Jacobowitz wrote:
>>On Tue, Feb 05, 2002 at 12:19:28AM -0500, Christopher Faylor wrote:
>>> On Thu, Jan 31, 2002 at 03:43:14PM -0500, Christopher Faylor wrote:
>>> >On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
>>> >>> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
>>> >>> If you build a cross compiler and try to link gdb, ld will fail, or
>>> >>> at least it does for me.
>>> >>
>>> >>Could you please try to reproduce this, and give me more exact
>>> >>instructions on how to make it bomb?
>>> >
>>> >Um.  Those were adequate instructions for making it bomb "for me".
>>> >
>>> >I'll rebuild a current CVS and see if it is fixed now.
>>> 
>>> Ok, I've rebuilt and confirmed that a link of gdb.exe now works.
>>> 
>>> Attempting to rebuild the Cygwin DLL (winsup/cygwin) or any C++
>>> utilities in winsup/utils seems to fail.
>>> 
>>> So, it looks like a c++ issue, maybe?  I rebuilt the entire toolchain
>>> with a very recent gcc + binutils + ld + gas and the link step failed.
>>> If I attempt to do the final link with an older toolchain, it works
>>> fine.
>>> 
>>> So, it seems like ld or maybe collect2 (?) is the culprit?
>>
>>Maybe I'm just dense.  I did a clean build, from a partially-combined
>>tree of CVS head GCC and binutils.  I built newlib, winsup, and all the
>>utils (cygcheck.exe etc.).  They all linked using the cygwin-targetted
>>assembler and self-built cygwin DLLs.
>>
>>Sorry, but to continue any further I need more information.
>
>I don't have any to offer, unfortunately.  can.  Perhaps you could be
>more specific about what information you require?
>
>Do you want me to send you object files?  Stub libraries?
>
>Just to be clear, I'm doing this all on linux.  Your mention of DLLs
>makes me think that you are possibly doing this on Windows although
>that's probably just a terminology problem since you don't normally use
>DLLs in linking.

Agh!

Nevermind.  I guess this has been a false alarm.  I just debugged ld
with gdb again and noticed that it was now dying in "new_op".  So, I
updated my version of libstdc++.a and rebuilt it.  No more SEGVs.

I had previously rebuilt libstdc++.a about a dozen times but I'd
convinced myself it had nothing to do with the problem.  Duh.

It's still a little odd, though, that the version of libstdc++.a that I
had caused the trunk version of ld to crash but worked ok with a three
month old version of ld.

So, apologies for the false alarm.  Especially since I know you (Dan)
didn't have a cygwin cross build toolchain on your system already...

cgf

Re: cygwin issues with 2.12 (was Re: Branching for 2.12)

[Daniel Jacobowitz]

On Sat, Feb 09, 2002 at 08:47:41PM -0500, Christopher Faylor wrote:
> On Fri, Feb 08, 2002 at 01:37:44AM -0500, Daniel Jacobowitz wrote:
> >On Tue, Feb 05, 2002 at 12:19:28AM -0500, Christopher Faylor wrote:
> >> On Thu, Jan 31, 2002 at 03:43:14PM -0500, Christopher Faylor wrote:
> >> >On Thu, Jan 31, 2002 at 12:15:25PM -0500, Daniel Jacobowitz wrote:
> >> >>> Windows target (i686-pc-cygwin), linux host.  Don't know about mingw.
> >> >>> If you build a cross compiler and try to link gdb, ld will fail, or
> >> >>> at least it does for me.
> >> >>
> >> >>Could you please try to reproduce this, and give me more exact
> >> >>instructions on how to make it bomb?
> >> >
> >> >Um.  Those were adequate instructions for making it bomb "for me".
> >> >
> >> >I'll rebuild a current CVS and see if it is fixed now.
> >> 
> >> Ok, I've rebuilt and confirmed that a link of gdb.exe now works.
> >> 
> >> Attempting to rebuild the Cygwin DLL (winsup/cygwin) or any C++
> >> utilities in winsup/utils seems to fail.
> >> 
> >> So, it looks like a c++ issue, maybe?  I rebuilt the entire toolchain
> >> with a very recent gcc + binutils + ld + gas and the link step failed.
> >> If I attempt to do the final link with an older toolchain, it works
> >> fine.
> >> 
> >> So, it seems like ld or maybe collect2 (?) is the culprit?
> >
> >Maybe I'm just dense.  I did a clean build, from a partially-combined
> >tree of CVS head GCC and binutils.  I built newlib, winsup, and all the
> >utils (cygcheck.exe etc.).  They all linked using the cygwin-targetted
> >assembler and self-built cygwin DLLs.
> >
> >Sorry, but to continue any further I need more information.
> 
> I don't have any to offer, unfortunately.  can.  Perhaps you could be
> more specific about what information you require?
> 
> Do you want me to send you object files?  Stub libraries?
> 
> Just to be clear, I'm doing this all on linux.  Your mention of DLLs
> makes me think that you are possibly doing this on Windows although
> that's probably just a terminology problem since you don't normally use
> DLLs in linking.

Sorry, getting confused with some MinGW stuff, I think.  I built a
cross tree (somewhat carefully, since I do not have GCC and binutils
checked out in the same tree - I might have messed something up, I'll
try it again).  I built all-target-newlib and all-target-winsup for
i386-pc-cygwin on an i386-linux host.  For whatever reason this
configuration chooses not to build any of the C++ applications in
winsup/utils/, so I fudged my configuration until it did.  They all
compiled without error.

Could you do a clean build in a combined tree, .... 

Or, having just gotten your other message, I guess we're good.  Thanks,
one more thing off the list.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Branching for 2.12

[Troy Rollo]

At 21:35 2/03/02 -0600, Joel Sherrill wrote:
>Have you uploaded anything else?  It doesn't look like any files
>have been publicly released yet.

The files are in the CVS repository.
______________________________________________________________________________
troy@rollo.com		IANALY,TINLA		  Troy Rollo, Sydney, Australia
       Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/

Re: Branching for 2.12

[Joel Sherrill]

Troy Rollo wrote:
> 
> At 12:10 1/03/02 +0000, Nick Clifton wrote:
> >Sorry, but as your patch stands, no.  There are two problems.  Firstly
> >we cannot accept automatically generated code (tds.[ch]) without the
> >program needed to regenerate that code.
> 
> I open-sourced it - <https://sourceforge.net/projects/dstrans/>. I put it
> there primarily because I won't have enough time to work on it myself most
> of the time, but it's a convenient place to keep it. Also, if somebody else
> wants to take it over the opportunity is there. I'd also be happy to sign
> it over to the FSF if they saw fit.

Have you uploaded anything else?  It doesn't look like any files
have been publicly released yet.

> On the other hand, there's no reason why the generated code couldn't be
> hand-modified, it just means (as you pointed out) that it couldn't be
> regenerated from the original files anymore.
> 
> I find manual writing of code of this nature tedious and error-prone, hence
> my spending more time on writing the generator than it would have taken to
> write the generated code by hand. I suspect many others would also prefer
> to be able to generate such code.
> 
> >Secondly these generated files are written in ANSI-C.  Binutils is
> >still using K&R C, so that they can be rebuilt on systems that only
> >provide a K&R C compiler.  (There still are such systems around).
> 
> OK - some of the other projects have converted, and I didn't look as
> closely at binutils as I probably should have. I can make the generator
> produce K&R syntax as an option easily enough.
> ______________________________________________________________________________
> troy@rollo.com          IANALY,TINLA              Troy Rollo, Sydney, Australia
>        Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

Re: Branching for 2.12

[Troy Rollo]

At 12:10 1/03/02 +0000, Nick Clifton wrote:
>Sorry, but as your patch stands, no.  There are two problems.  Firstly
>we cannot accept automatically generated code (tds.[ch]) without the
>program needed to regenerate that code.

I open-sourced it - <https://sourceforge.net/projects/dstrans/>. I put it 
there primarily because I won't have enough time to work on it myself most 
of the time, but it's a convenient place to keep it. Also, if somebody else 
wants to take it over the opportunity is there. I'd also be happy to sign 
it over to the FSF if they saw fit.

On the other hand, there's no reason why the generated code couldn't be 
hand-modified, it just means (as you pointed out) that it couldn't be 
regenerated from the original files anymore.

I find manual writing of code of this nature tedious and error-prone, hence 
my spending more time on writing the generator than it would have taken to 
write the generated code by hand. I suspect many others would also prefer 
to be able to generate such code.

>Secondly these generated files are written in ANSI-C.  Binutils is
>still using K&R C, so that they can be rebuilt on systems that only
>provide a K&R C compiler.  (There still are such systems around).

OK - some of the other projects have converted, and I didn't look as 
closely at binutils as I probably should have. I can make the generator 
produce K&R syntax as an option easily enough.
______________________________________________________________________________
troy@rollo.com		IANALY,TINLA		  Troy Rollo, Sydney, Australia
       Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/

Re: Branching for 2.12

[Nick Clifton]

Hi Troy,

> I notice that my patches for recognising Borland TDS files, posted
> here nearly a year ago (see
> http://sources.redhat.com/ml/binutils/2001-02/msg00408.html), are not
> in the CVS tree. Are there any plans to put them in?

Sorry, but as your patch stands, no.  There are two problems.  Firstly
we cannot accept automatically generated code (tds.[ch]) without the
program needed to regenerate that code.  If bugs are ever found in
those files we need to be able to fix them.  If we just patch the
generated files, then the next time you regenerate them the patches
will be lost.

Secondly these generated files are written in ANSI-C.  Binutils is
still using K&R C, so that they can be rebuilt on systems that only
provide a K&R C compiler.  (There still are such systems around).

Cheers
        Nick

Re: Branching for 2.12

[Danny Smith]

 --- Daniel Jacobowitz <drow@mvista.com> wrote: > On Wed, Jan 30, 2002 at
05:29:51AM +1100, Danny Smith wrote:
> > This bug is still present on mingw  target.
> >  
> > RE: http://sources.redhat.com/ml/binutils/2002-01/msg00477.html
> > 
> > 
> > I am still having probelms with dll import libs built with ld -shared
> > since hash lookup of sections was introduced  on 2001-12-17. 
> > 
> > With this testcase, test,c
> > /* test.c */
> > int __attribute__((dllexport)) 
> > dll_int (int i)
> > {
> >   return i * i;
> > }
> > 
> > and using binutils from 20011216,
> > this script
> 
> I'm sorry, but since no one has stepped forward to look at this it will
> not be fixed in 2.12 (which is getting rapidly closer).
> 
> I spent all of this evening attempting to build a mingw32 toolchain.  I
> can't do it; no matter what I try gcc dies unable to find limits.h when
> building winsup.
> 
> I hacked around that, and was able to build a 'bad' DLL.  Looking at
> make_head, I bet I know what is wrong, but I don't know how to fix it:
> offsets in one section pointing into another following section.  The
> sections are presumably coming out in a different order.
> 
> So either someone else feels like fixing this, or it waits.

Thanks very much for trying.  I don't know how to fix it either, but I'll
try to learn.
Danny

> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer 

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

Re: Branching for 2.12

[Daniel Jacobowitz]

On Wed, Jan 30, 2002 at 05:29:51AM +1100, Danny Smith wrote:
> This bug is still present on mingw  target.
>  
> RE: http://sources.redhat.com/ml/binutils/2002-01/msg00477.html
> 
> 
> I am still having probelms with dll import libs built with ld -shared
> since hash lookup of sections was introduced  on 2001-12-17. 
> 
> With this testcase, test,c
> /* test.c */
> int __attribute__((dllexport)) 
> dll_int (int i)
> {
>   return i * i;
> }
> 
> and using binutils from 20011216,
> this script

I'm sorry, but since no one has stepped forward to look at this it will
not be fixed in 2.12 (which is getting rapidly closer).

I spent all of this evening attempting to build a mingw32 toolchain.  I
can't do it; no matter what I try gcc dies unable to find limits.h when
building winsup.

I hacked around that, and was able to build a 'bad' DLL.  Looking at
make_head, I bet I know what is wrong, but I don't know how to fix it:
offsets in one section pointing into another following section.  The
sections are presumably coming out in a different order.

So either someone else feels like fixing this, or it waits.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Branching for 2.12

[Troy Rollo]

I notice that my patches for recognising Borland TDS files, posted here 
nearly a year ago (see 
http://sources.redhat.com/ml/binutils/2001-02/msg00408.html), are not in 
the CVS tree. Are there any plans to put them in? The changes should be low 
to no potential for side-effects (the diffs being extremely small and 
easily checked, and most of the real work being in the additional files).
__________________________________________________________________________
Troy Rollo, Sydney, Australasia	IANALY,TINLA	troy@rollo.com
    Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/

Re: Branching for 2.12

[Danny Smith]

This bug is still present on mingw  target.
 
RE: http://sources.redhat.com/ml/binutils/2002-01/msg00477.html


I am still having probelms with dll import libs built with ld -shared
since hash lookup of sections was introduced  on 2001-12-17. 

With this testcase, test,c
/* test.c */
int __attribute__((dllexport)) 
dll_int (int i)
{
  return i * i;
}

and using binutils from 20011216,
this script

gcc -shared -v -o test20011216.dll -Bd:/binutils-20011216/bin/ \
	-Wl,--out-implib,lib20011216.a  test.c
pedump lib20011216.a

produces a good imort lib:

Contents of LIB20011216.A 1478 bytes


Archive header:1
Name:'/               '
Date:' 1012247688 (Tue Jan 29 07:54:48 2002) '
User id:'0     '
Group id:'0     '
File Mode:'0       '
File Size:'110       '

First linker member
----- ------ ------
5 (5) symbols contained in the archive
[   0] _test20011216_dll_iname Offset 178
[   1] __head_test20011216_dll Offset 506
[   2] _dll_int Offset 906
[   3] __imp__dll_int Offset 906
[   4] __nm__dll_int Offset 906

Archive header:2
<snip>

That one works.

While using  binutils from 20011217 (or later),

gcc -shared -v -o test20011217.dll -Bd:/binutils-20011217/bin/ \
	-Wl,--out-implib,lib20011217.a  test.c
pedump lib20011217.a

produces:

Contents of LIB20011217.A 1372 bytes


Archive header:1
Name:'/               '
Date:' 1012247692 (Tue Jan 29 07:54:52 2002) '
User id:'0     '
Group id:'0     '
File Mode:'0       '
File Size:'4         '

First linker member
----- ------ ------
0 (0) symbols contained in the archive

Archive header:2
<snip>

That one of course fails.  The dll itself, however, is ok. 

I suspect the code in ld/pd-dll.c, particularly, here in make_head(),


line 1591 and follows:
  /* OK, pay attention here.  I got confused myself looking back at
     it.  We create a four-byte section to mark the beginning of the
     list, and we include an offset of 4 in the section, so that the
     pointer to the list points to the *end* of this section, which is
     the start of the list of sections from other objects.  */


I can't, however, see what am I missing, since make_head is also used to
build dll and that works.  The problem is only in the list head in the
import lib.  
Danny


http://my.yahoo.com.au - My Yahoo!
- It's My Yahoo! Get your own!