RE: Q: Estimated date for 2.16 release ?

RE: Q: Estimated date for 2.16 release ?

[Anil Paranjape]

Hi Nick,

On behalf of KPIT Cummins, I am ready to be a maintainer of H8/300 port in Binutils.

Best regards,
Anil Paranjpe
KPIT Cummins InfoSystems Ltd.
Pune, India

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools were released on February 4, 2005.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com]
Sent: Monday, February 14, 2005 10:19 PM
To: Anil Paranjape
Cc: binutils@sources.redhat.com
Subject: Re: Q: Estimated date for 2.16 release ?


Hi Anil,

> We are very keen to become maintainers for H8/300 target in Binutils. I would be grateful if you could tell me ( or give a link) which describes maintainer responsibilities. We will do our best to fulfill them. 

There is a lot of information about maintainership of GNU projects at 
this site:

http://www.gnu.org/prep/maintain/

The good news however is that for binutils being a maintainer of a port 
  to a particular target is lot simpler.  So instead take a look at this 
file:

   <binutils-sources>/binutils/MAINTAINERS

and in particular the section on maintainers.

So if you feel that you can work to improve the h8/300 port, review 
changes by other people to h8/300 specific files,  and watch for changes 
to the generic code that adversely affects the h8/300 port then you are 
suitable to be a maintainer fir the h8/300 port.

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Anil,

> On behalf of KPIT Cummins, I am ready to be a maintainer of H8/300 port in Binutils.

Great - as your first act as a maintainer, please could you add your 
name to the list of port specific maintainers in the 
binutils/MAINTAINERS file ?

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Thorsten Glaser]

Dixi:

>Daniel Jacobowitz dixit:
>
>>Yes, that's the right way to do it.  I don't much intend to see these
>>in 2.16, though.
[...]

Okay, I think I can start feeding back patches now.

I didn't found a document similar to "GCC Contribution HOWTO"
for binutils, so whom do I ask for write access? I've got the
paperwork done already, but that's about it.

bye,
//mirabile

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Mon, Mar 21, 2005 at 12:37:11PM +1030, Alan Modra wrote:
> On Thu, Feb 24, 2005 at 12:44:34PM -0500, Daniel Jacobowitz wrote:
> > 	* config/obj-vms.h, config/obj-vms.c, config/vms-conf.h: Remove.
> 
> Cleaning up after Daniel.  ;)
> 
> 	* Makefile.am (OBJ_FORMAT_CFILES): Prune config/obj-vms.c.
> 	(OBJ_FORMAT_HFILES): Prune config/obj-vms.h.
> 	(obj-vms.o): Delete rule.
> 	Run "make dep-am".
> 	* Makefile.in: Regenerate.
> 	* aclocal.m4: Regenerate.
> 	* doc/Makefile.in: Regenerate.
> 	* po/POTFILES.in: Regenerate.

Thanks.  Wow, that's a lot of bits...


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Q: Estimated date for 2.16 release ?

[Alan Modra]

On Thu, Feb 24, 2005 at 12:44:34PM -0500, Daniel Jacobowitz wrote:
> 	* config/obj-vms.h, config/obj-vms.c, config/vms-conf.h: Remove.

Cleaning up after Daniel.  ;)

	* Makefile.am (OBJ_FORMAT_CFILES): Prune config/obj-vms.c.
	(OBJ_FORMAT_HFILES): Prune config/obj-vms.h.
	(obj-vms.o): Delete rule.
	Run "make dep-am".
	* Makefile.in: Regenerate.
	* aclocal.m4: Regenerate.
	* doc/Makefile.in: Regenerate.
	* po/POTFILES.in: Regenerate.

Index: gas/Makefile.am
===================================================================
RCS file: /cvs/src/src/gas/Makefile.am,v
retrieving revision 1.102
diff -u -p -r1.102 Makefile.am
--- gas/Makefile.am	15 Mar 2005 05:28:12 -0000	1.102
+++ gas/Makefile.am	21 Mar 2005 00:33:53 -0000
@@ -354,8 +354,7 @@ OBJ_FORMAT_CFILES = \
 	config/obj-evax.c \
 	config/obj-hp300.c \
 	config/obj-ieee.c \
-	config/obj-som.c \
-	config/obj-vms.c
+	config/obj-som.c
 
 OBJ_FORMAT_HFILES = \
 	config/obj-aout.h \
@@ -366,8 +365,7 @@ OBJ_FORMAT_HFILES = \
 	config/obj-evax.h \
 	config/obj-hp300.h \
 	config/obj-ieee.h \
-	config/obj-som.h \
-	config/obj-vms.h
+	config/obj-som.h
 
 # Emulation header files in config
 
@@ -598,8 +596,6 @@ obj-multi.o : $(srcdir)/config/obj-multi
 	$(COMPILE) -c $(srcdir)/config/obj-multi.c
 obj-som.o : $(srcdir)/config/obj-som.c
 	$(COMPILE) -c $(srcdir)/config/obj-som.c
-obj-vms.o : $(srcdir)/config/obj-vms.c
-	$(COMPILE) -c $(srcdir)/config/obj-vms.c
 
 e-mipself.o : $(srcdir)/config/e-mipself.c
 	$(COMPILE) -c $(srcdir)/config/e-mipself.c
@@ -1518,11 +1514,6 @@ DEPTC_vax_elf = $(INCDIR)/symcat.h $(src
   $(srcdir)/config/vax-inst.h $(INCDIR)/obstack.h subsegs.h \
   $(INCDIR)/elf/vax.h $(INCDIR)/elf/reloc-macros.h $(INCDIR)/opcode/vax.h \
   $(INCDIR)/safe-ctype.h
-DEPTC_vax_vms = $(INCDIR)/symcat.h $(srcdir)/config/obj-vms.h \
-  $(srcdir)/config/tc-vax.h $(INCDIR)/aout/stab_gnu.h \
-  $(INCDIR)/aout/stab.def $(srcdir)/config/vax-inst.h \
-  $(INCDIR)/obstack.h subsegs.h $(INCDIR)/opcode/vax.h \
-  $(INCDIR)/safe-ctype.h
 DEPTC_w65_coff = $(INCDIR)/symcat.h $(srcdir)/config/obj-coff.h \
   $(srcdir)/config/tc-w65.h $(INCDIR)/coff/internal.h \
   $(INCDIR)/coff/w65.h $(INCDIR)/coff/external.h $(BFDDIR)/libcoff.h \
@@ -2043,10 +2034,6 @@ DEPOBJ_vax_elf = $(INCDIR)/symcat.h $(sr
   $(INCDIR)/elf/external.h $(INCDIR)/bfdlink.h $(srcdir)/config/tc-vax.h \
   $(INCDIR)/safe-ctype.h subsegs.h $(INCDIR)/obstack.h \
   struc-symbol.h dwarf2dbg.h $(INCDIR)/aout/aout64.h
-DEPOBJ_vax_vms = $(INCDIR)/symcat.h $(srcdir)/config/obj-vms.h \
-  $(srcdir)/config/tc-vax.h $(INCDIR)/aout/stab_gnu.h \
-  $(INCDIR)/aout/stab.def $(INCDIR)/safe-ctype.h subsegs.h \
-  $(INCDIR)/obstack.h
 DEPOBJ_w65_coff = $(INCDIR)/symcat.h $(srcdir)/config/obj-coff.h \
   $(srcdir)/config/tc-w65.h $(INCDIR)/coff/internal.h \
   $(INCDIR)/coff/w65.h $(INCDIR)/coff/external.h $(BFDDIR)/libcoff.h \
@@ -2404,8 +2391,6 @@ DEP_vax_coff = $(srcdir)/config/obj-coff
 DEP_vax_elf = $(srcdir)/config/obj-elf.h $(INCDIR)/symcat.h \
   $(BFDDIR)/elf-bfd.h $(INCDIR)/elf/common.h $(INCDIR)/elf/internal.h \
   $(INCDIR)/elf/external.h $(INCDIR)/bfdlink.h $(srcdir)/config/tc-vax.h
-DEP_vax_vms = $(srcdir)/config/obj-vms.h $(srcdir)/config/tc-vax.h \
-  $(INCDIR)/aout/stab_gnu.h $(INCDIR)/aout/stab.def
 DEP_w65_coff = $(srcdir)/config/obj-coff.h $(srcdir)/config/tc-w65.h \
   $(INCDIR)/symcat.h $(INCDIR)/coff/internal.h $(INCDIR)/coff/w65.h \
   $(INCDIR)/coff/external.h $(BFDDIR)/libcoff.h $(INCDIR)/bfdlink.h
Index: gas/po/POTFILES.in
===================================================================
RCS file: /cvs/src/src/gas/po/POTFILES.in,v
retrieving revision 1.26
diff -u -p -r1.26 POTFILES.in
--- gas/po/POTFILES.in	21 Feb 2005 11:49:31 -0000	1.26
+++ gas/po/POTFILES.in	21 Mar 2005 00:34:00 -0000
@@ -38,8 +38,6 @@ config/obj-ieee.c
 config/obj-ieee.h
 config/obj-som.c
 config/obj-som.h
-config/obj-vms.c
-config/obj-vms.h
 config/tc-a29k.c
 config/tc-a29k.h
 config/tc-alpha.c

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Daniel,

>>2005-02-24  Daniel Jacobowitz  <dan@codesourcery.com>
>>
>>	* config-gas.com: Mark vax-vms as obsolete.
>>	* configure.in: Remove fmt=vms support.
>>	* config.in: Regenerate.
>>	* configure: Regenerate.
>>	* config/obj-vms.h, config/obj-vms.c, config/vms-conf.h: Remove.
>>
>>2005-02-24  Daniel Jacobowitz  <dan@codesourcery.com>
>>
>>	* Makefile.am: Remove references to em68klynx.o and esparclynx.o.
>>	* emulparams/m68klynx.sh, emulparams/sparclynx.sh: Remove.
>>

Approved - please apply.

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Thu, Feb 24, 2005 at 12:44:34PM -0500, Daniel Jacobowitz wrote:
> This leaves a couple of orphaned files - at least, I'm pretty sure
> they're orphaned.  This OK?

Ping.

> 2005-02-24  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* config-gas.com: Mark vax-vms as obsolete.
> 	* configure.in: Remove fmt=vms support.
> 	* config.in: Regenerate.
> 	* configure: Regenerate.
> 	* config/obj-vms.h, config/obj-vms.c, config/vms-conf.h: Remove.
> 
> 2005-02-24  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* Makefile.am: Remove references to em68klynx.o and esparclynx.o.
> 	* emulparams/m68klynx.sh, emulparams/sparclynx.sh: Remove.
> 
> Index: gas/config-gas.com
> ===================================================================
> RCS file: /big/fsf/rsync/src-cvs/src/gas/config-gas.com,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 config-gas.com
> --- gas/config-gas.com	3 May 1999 07:28:40 -0000	1.1.1.1
> +++ gas/config-gas.com	24 Feb 2005 17:37:37 -0000
> @@ -3,6 +3,9 @@ $! This file sets things up to build gas
>  $! files for a VMS system.  We do not use the configure script, since we
>  $! do not have /bin/sh to execute it.
>  $!
> +$! Note: Only this script contains vax-vms and alpha-vms support, but vax-vms
> +$! is no longer supported.
> +$!
>  $!
>  $ gas_host="vms"
>  $ arch_indx = 1 + ((f$getsyi("CPU").ge.128).and.1)	! vax==1, alpha==2
> Index: gas/configure.in
> ===================================================================
> RCS file: /big/fsf/rsync/src-cvs/src/gas/configure.in,v
> retrieving revision 1.168
> diff -u -p -r1.168 configure.in
> --- gas/configure.in	22 Dec 2004 15:29:25 -0000	1.168
> +++ gas/configure.in	24 Feb 2005 17:35:51 -0000
> @@ -545,7 +545,6 @@ if test `set . $formats ; shift ; echo $
>        hp300)	AC_DEFINE(OBJ_MAYBE_HP300, 1,   [HP300 support?])   ;;
>        ieee)	AC_DEFINE(OBJ_MAYBE_IEEE, 1,    [IEEE support?])    ;;
>        som)	AC_DEFINE(OBJ_MAYBE_SOM, 1,     [SOM support?])     ;;
> -      vms)	AC_DEFINE(OBJ_MAYBE_VMS, 1,     [VMS support?])     ;;
>      esac
>      extra_objects="$extra_objects obj-$fmt.o"
>    done
> Index: ld/Makefile.am
> ===================================================================
> RCS file: /big/fsf/rsync/src-cvs/src/ld/Makefile.am,v
> retrieving revision 1.169
> diff -u -p -r1.169 Makefile.am
> --- ld/Makefile.am	20 Jan 2005 19:37:49 -0000	1.169
> +++ ld/Makefile.am	24 Feb 2005 17:40:01 -0000
> @@ -249,7 +249,6 @@ ALL_EMULATIONS = \
>  	em68kelf.o \
>  	em68kelfnbsd.o \
>  	em68klinux.o \
> -	em68klynx.o \
>  	em68knbsd.o \
>  	em68kpsos.o \
>  	em88kbcs.o \
> @@ -351,7 +350,6 @@ ALL_EMULATIONS = \
>  	eshpe.o \
>  	esparcaout.o \
>  	esparclinux.o \
> -	esparclynx.o \
>  	esparcnbsd.o \
>  	est2000.o \
>  	esun3.o \
> @@ -1050,9 +1048,6 @@ em68kelfnbsd.c: $(srcdir)/emulparams/m68
>  em68klinux.c: $(srcdir)/emulparams/m68klinux.sh \
>    $(srcdir)/emultempl/linux.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
>  	${GENSCRIPTS} m68klinux "$(tdir_m68klinux)"
> -em68klynx.c: $(srcdir)/emulparams/m68klynx.sh \
> -  $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/m68klynx.sc ${GEN_DEPENDS}
> -	${GENSCRIPTS} m68klynx "$(tdir_m68klynx)"
>  em68knbsd.c:	$(srcdir)/emulparams/m68knbsd.sh \
>    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
>  	${GENSCRIPTS} m68knbsd "$(tdir_m68knbsd)"
> @@ -1458,9 +1453,6 @@ esparcaout.c: $(srcdir)/emulparams/sparc
>  esparclinux.c: $(srcdir)/emulparams/sparclinux.sh \
>    $(srcdir)/emultempl/linux.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
>  	${GENSCRIPTS} sparclinux "$(tdir_sparclinux)"
> -esparclynx.c: $(srcdir)/emulparams/sparclynx.sh \
> -  $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/sparclynx.sc ${GEN_DEPENDS}
> -	${GENSCRIPTS} sparclynx "$(tdir_sparclynx)"
>  esparcnbsd.c:	$(srcdir)/emulparams/sparcnbsd.sh \
>    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
>  	${GENSCRIPTS} sparcnbsd "$(tdir_sparcnbsd)"
> 

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: Q: Estimated date for 2.16 release ?

[Anil Paranjape]

Hi Nick,

I need to request for an account which will give me CVS write access.
I have provided your name as approver for my request.

As soon as my account is enabled, i will add my name into list of port specific maintainers
in the binutils/MAINTAINERS file.

Regards,
Anil Paranjpe
KPIT Cummins InfoSystems Ltd.
Pune, India

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools were released on February 4, 2005.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com]
Sent: Wednesday, February 16, 2005 5:39 PM
To: Anil Paranjape
Cc: binutils@sources.redhat.com
Subject: Re: Q: Estimated date for 2.16 release ?


Hi Anil,

> On behalf of KPIT Cummins, I am ready to be a maintainer of H8/300 port in Binutils.

Great - as your first act as a maintainer, please could you add your 
name to the list of port specific maintainers in the 
binutils/MAINTAINERS file ?

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Eric Norum]

On Feb 24, 2005, at 11:49 AM, Joel Sherrill <joel@OARcorp.com> wrote:

> Daniel Jacobowitz wrote:
>> On Thu, Jan 27, 2005 at 09:36:11AM -0500, Hans-Peter Nilsson wrote:
>>> On Thu, 27 Jan 2005, Joel Sherrill <joel@OARcorp.com> wrote:
>>>
>>>> http://sources.redhat.com/ml/binutils/2004-03/msg00489.html
>>>>
>>>> Eric Norum (cc'ed) recently narrowed it down to this construct:
>>>>
>>>> =============================================================
>>>> A little poking around reveals that it's the lines like:
>>>>
>>>> _RamBase = DEFINED(_RamBase) ? _RamBase : 0x0;
>>>> _RamSize = DEFINED(_RamSize) ? _RamSize : 0x7f0000;
>>>> _HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0;   /* 0x20000;*/
>>>> _StackSize = DEFINED(_StackSize) ? _StackSize : 1M; /* 0x2000;*/
>>>>
>>>> that are killing ld.
>>>> ==============================================================
>>>>
>>>> Does this sound familiar?
>>>
>>> Yes. :-(  The semantics of DEFINED has changed.  IIRC, my patch
>>> to announce that in ld/NEWS before 2.15 received no comments.
>>> The usage above should still work, though.
>>>
>>> Can you open a PR with binutils-self-contained (only assembly
>>> files, no C or objects) test-case?  Maybe all was at the URL
>>> above, but I don't see the ld command line.  Still, please open
>>> a PR.
>> Was a PR ever created for this?  Has anyone looked at it?
>
> Not that I know of.
>
> Eric.. if you have a .c file and simple linkcmds that produces this,
> then just use the -S option to put together a binutils test case.

I didn't worry about this any more after I found that the problem went 
away if I changed my application link-edit command as follows (from 
RTEMS/make/custrom/uC5282.cfg):
  define make-exe
-       $(LINK.c) $(AM_CFLAGS) -m5200 $(AM_LDFLAGS) -qnolinkcmds -o 
$(basename $@).nxe \
-           $(LINK_OBJS) $(LINK_LIBS) -Wl,-Tlinkcmds
+       $(LINK.c) $(AM_CFLAGS) $(AM_LDFLAGS) -o $(basename $@).nxe \
+           $(LINK_OBJS) $(LINK_LIBS)
         $(OBJCOPY) -O binary --strip-all $(basename $@).nxe $@
         $(SIZE) $(basename $@).nxe
  endef

-- 
Eric Norum <norume@aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

Re: Q: Estimated date for 2.16 release ?

[Joel Sherrill <joel@OARcorp.com>]

Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 09:36:11AM -0500, Hans-Peter Nilsson wrote:
> 
>>On Thu, 27 Jan 2005, Joel Sherrill <joel@OARcorp.com> wrote:
>>
>>>http://sources.redhat.com/ml/binutils/2004-03/msg00489.html
>>>
>>>Eric Norum (cc'ed) recently narrowed it down to this construct:
>>>
>>>=============================================================
>>>A little poking around reveals that it's the lines like:
>>>
>>>_RamBase = DEFINED(_RamBase) ? _RamBase : 0x0;
>>>_RamSize = DEFINED(_RamSize) ? _RamSize : 0x7f0000;
>>>_HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0;   /* 0x20000;*/
>>>_StackSize = DEFINED(_StackSize) ? _StackSize : 1M; /* 0x2000;*/
>>>
>>>that are killing ld.
>>>==============================================================
>>>
>>>Does this sound familiar?
>>
>>Yes. :-(  The semantics of DEFINED has changed.  IIRC, my patch
>>to announce that in ld/NEWS before 2.15 received no comments.
>>The usage above should still work, though.
>>
>>Can you open a PR with binutils-self-contained (only assembly
>>files, no C or objects) test-case?  Maybe all was at the URL
>>above, but I don't see the ld command line.  Still, please open
>>a PR.
> 
> 
> Was a PR ever created for this?  Has anyone looked at it?

Not that I know of.

Eric.. if you have a .c file and simple linkcmds that produces this,
then just use the -S option to put together a binutils test case.

Thanks.

--joel

Re: Q: Estimated date for 2.16 release ?

[Hans-Peter Nilsson]

On Thu, 24 Feb 2005, Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 09:36:11AM -0500, Hans-Peter Nilsson wrote:
> > On Thu, 27 Jan 2005, Joel Sherrill <joel@OARcorp.com> wrote:
> > > http://sources.redhat.com/ml/binutils/2004-03/msg00489.html
> Was a PR ever created for this?  Has anyone looked at it?

I have no answer.

brgds, H-P

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Thu, Jan 27, 2005 at 09:00:10AM -0500, Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:
> > Hi Nick,
> > 
> > Is there any estimated date for the next Binutils formal release (version 
> > 2.16) ?
> > We would like to plan our work accordingly.
> 
> There is no plan yet.  I would like to branch sometime very soon; does
> anyone know of issues that need to be resolved before the next release?

It sounds like it's time to create the branch.  I'll plan on doing it
next week, unless there are any objections.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Thu, Jan 27, 2005 at 09:36:11AM -0500, Hans-Peter Nilsson wrote:
> On Thu, 27 Jan 2005, Joel Sherrill <joel@OARcorp.com> wrote:
> > http://sources.redhat.com/ml/binutils/2004-03/msg00489.html
> >
> > Eric Norum (cc'ed) recently narrowed it down to this construct:
> >
> > =============================================================
> > A little poking around reveals that it's the lines like:
> >
> > _RamBase = DEFINED(_RamBase) ? _RamBase : 0x0;
> > _RamSize = DEFINED(_RamSize) ? _RamSize : 0x7f0000;
> > _HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0;   /* 0x20000;*/
> > _StackSize = DEFINED(_StackSize) ? _StackSize : 1M; /* 0x2000;*/
> >
> > that are killing ld.
> > ==============================================================
> >
> > Does this sound familiar?
> 
> Yes. :-(  The semantics of DEFINED has changed.  IIRC, my patch
> to announce that in ld/NEWS before 2.15 received no comments.
> The usage above should still work, though.
> 
> Can you open a PR with binutils-self-contained (only assembly
> files, no C or objects) test-case?  Maybe all was at the URL
> above, but I don't see the ld command line.  Still, please open
> a PR.

Was a PR ever created for this?  Has anyone looked at it?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Mon, Jan 31, 2005 at 05:24:29PM +0000, Nick Clifton wrote:
> Hi Daniel,
> 
> >>I had a discussion with Alan Modra last week and we agreed that a more
> >>aggressive target deprecation policy would be a good idea,
> 
> >Yes.  Someone should take charge of doing that, starting with removing
> >the targets currently marked obsolete :-)
> 
> I have checked in the attached patch to do this.
> 
> Cheers
>   Nick
> 
> bfd/ChangeLog
> 2005-01-31  Nick Clifton  <nickc@redhat.com>
> 
> 	* confg.bfd: Make targets scheduled for obsoletion (m68k-lynxos,
> 	sparc-lynxos, vax-vms) be obsolete.
> 
> ld/ChangeLog
> 2005-01-31  Nick Clifton  <nickc@redhat.com>
> 
> 	* configure.tgt: Remove obsolete targets m68k-lynxos and
> 	sparc-lynxos.
> 
> gas/ChangeLog
> 2005-01-31  Nick Clifton  <nickc@redhat.com>
> 
> 	* configure.tgt: Remove obsolete targets m68k-lynxos, sparc-lynxos
> 	and vax-vms.

Thank you, Nick!

This leaves a couple of orphaned files - at least, I'm pretty sure
they're orphaned.  This OK?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

2005-02-24  Daniel Jacobowitz  <dan@codesourcery.com>

	* config-gas.com: Mark vax-vms as obsolete.
	* configure.in: Remove fmt=vms support.
	* config.in: Regenerate.
	* configure: Regenerate.
	* config/obj-vms.h, config/obj-vms.c, config/vms-conf.h: Remove.

2005-02-24  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.am: Remove references to em68klynx.o and esparclynx.o.
	* emulparams/m68klynx.sh, emulparams/sparclynx.sh: Remove.

Index: gas/config-gas.com
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gas/config-gas.com,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 config-gas.com
--- gas/config-gas.com	3 May 1999 07:28:40 -0000	1.1.1.1
+++ gas/config-gas.com	24 Feb 2005 17:37:37 -0000
@@ -3,6 +3,9 @@ $! This file sets things up to build gas
 $! files for a VMS system.  We do not use the configure script, since we
 $! do not have /bin/sh to execute it.
 $!
+$! Note: Only this script contains vax-vms and alpha-vms support, but vax-vms
+$! is no longer supported.
+$!
 $!
 $ gas_host="vms"
 $ arch_indx = 1 + ((f$getsyi("CPU").ge.128).and.1)	! vax==1, alpha==2
Index: gas/configure.in
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/gas/configure.in,v
retrieving revision 1.168
diff -u -p -r1.168 configure.in
--- gas/configure.in	22 Dec 2004 15:29:25 -0000	1.168
+++ gas/configure.in	24 Feb 2005 17:35:51 -0000
@@ -545,7 +545,6 @@ if test `set . $formats ; shift ; echo $
       hp300)	AC_DEFINE(OBJ_MAYBE_HP300, 1,   [HP300 support?])   ;;
       ieee)	AC_DEFINE(OBJ_MAYBE_IEEE, 1,    [IEEE support?])    ;;
       som)	AC_DEFINE(OBJ_MAYBE_SOM, 1,     [SOM support?])     ;;
-      vms)	AC_DEFINE(OBJ_MAYBE_VMS, 1,     [VMS support?])     ;;
     esac
     extra_objects="$extra_objects obj-$fmt.o"
   done
Index: ld/Makefile.am
===================================================================
RCS file: /big/fsf/rsync/src-cvs/src/ld/Makefile.am,v
retrieving revision 1.169
diff -u -p -r1.169 Makefile.am
--- ld/Makefile.am	20 Jan 2005 19:37:49 -0000	1.169
+++ ld/Makefile.am	24 Feb 2005 17:40:01 -0000
@@ -249,7 +249,6 @@ ALL_EMULATIONS = \
 	em68kelf.o \
 	em68kelfnbsd.o \
 	em68klinux.o \
-	em68klynx.o \
 	em68knbsd.o \
 	em68kpsos.o \
 	em88kbcs.o \
@@ -351,7 +350,6 @@ ALL_EMULATIONS = \
 	eshpe.o \
 	esparcaout.o \
 	esparclinux.o \
-	esparclynx.o \
 	esparcnbsd.o \
 	est2000.o \
 	esun3.o \
@@ -1050,9 +1048,6 @@ em68kelfnbsd.c: $(srcdir)/emulparams/m68
 em68klinux.c: $(srcdir)/emulparams/m68klinux.sh \
   $(srcdir)/emultempl/linux.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
 	${GENSCRIPTS} m68klinux "$(tdir_m68klinux)"
-em68klynx.c: $(srcdir)/emulparams/m68klynx.sh \
-  $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/m68klynx.sc ${GEN_DEPENDS}
-	${GENSCRIPTS} m68klynx "$(tdir_m68klynx)"
 em68knbsd.c:	$(srcdir)/emulparams/m68knbsd.sh \
   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
 	${GENSCRIPTS} m68knbsd "$(tdir_m68knbsd)"
@@ -1458,9 +1453,6 @@ esparcaout.c: $(srcdir)/emulparams/sparc
 esparclinux.c: $(srcdir)/emulparams/sparclinux.sh \
   $(srcdir)/emultempl/linux.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
 	${GENSCRIPTS} sparclinux "$(tdir_sparclinux)"
-esparclynx.c: $(srcdir)/emulparams/sparclynx.sh \
-  $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/sparclynx.sc ${GEN_DEPENDS}
-	${GENSCRIPTS} sparclynx "$(tdir_sparclynx)"
 esparcnbsd.c:	$(srcdir)/emulparams/sparcnbsd.sh \
   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
 	${GENSCRIPTS} sparcnbsd "$(tdir_sparcnbsd)"

Re: Q: Estimated date for 2.16 release ?

[Thorsten Glaser]

Daniel Jacobowitz dixit:

>Yes, that's the right way to do it.  I don't much intend to see these
>in 2.16, though.

Sure, I'm going with CVS snapshots at the moment anyway (until we are
_really_ near a release ourselfes) and I don't want to have impact on
the other OSes.
Since one of the patches (elf32.em) is quite a complicated one, I
figured that after releasing (or rather branching) 2.16 would be the
best point to feed it back so it gets tested the most.

bye,
//mirabile
-- 
> [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der
> richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt.
Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...]
weil selbst einfachste Operationen *echt* *Zeit* brauchen.	(aus d.a.s.r)

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Sun, Jan 30, 2005 at 09:10:52PM -0500, Hans-Peter Nilsson wrote:
> On Thu, 27 Jan 2005, Daniel Jacobowitz wrote:
> > On Thu, Jan 27, 2005 at 10:56:30AM -0500, Hans-Peter Nilsson wrote:
> > > On Thu, 27 Jan 2005, Ian Lance Taylor wrote:
> > > > Hans-Peter Nilsson <hp@bitrange.com> writes:
> > > > > BTW, was the intl/ directory about to be added to binutils?
> > > > > Maybe that and the fallout should be done before the release.
> > > > > Or maybe better done after branching?
> > > > The binutils releases already have an intl directory, don't they?
> > > > They used to, and it seems to me that they still do.
> > >
> > > Oh right you are, problem misdiagnosed.  Still a problem,
> > > though, and one that would be good to fix before the next
> > > release.
> >
> > It's more complicated than you think :-)
> 
> Uh, remind me: what did I think?  (I made no claim about
> simplicity above. ;-)
> 
> FWIW, one workaround is to remove the intl directory from the
> combined sources.  Perhaps better than upgrading binutils to
> autoconf 2.59 at this time (which would seem necessary in order
> to sync the intl machinery).

Anyway, it sounds like this is specifically related to combined builds,
and therefore not an issue for 2.16; if you try to combine released
toolchain components rather than HEAD, this is the least of your
problems :-)

> Anyway, I've seen a problem with the stabs linker-warning
> machinery (see libgloss/libnosys/warning.h) and a.out; there's a
> SEGV which valgrind says is an invalid access, after allocated
> memory.  Valgrind also changes the behavior and instead of the
> linker warnings, the symbols are undefined.  PR and testcase
> later.

I believe that you've fixed this since the above message.  Am I
remembering rightly?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Mon, Jan 31, 2005 at 12:03:24PM +1100, Ben Elliston wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > > Have the simple installation problems from 2.15 been worked out?
> > 
> > Could you remind me which specific problems you are referring to?
> 
> I recall a straightforward bug that affected all Solaris users, at
> least.  Perhaps there are others.

The only one I know of was a problem finding install-sh; I fixed it
several months ago.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Thu, Jan 27, 2005 at 06:44:56PM +0000, Thorsten Glaser wrote:
> Daniel Jacobowitz dixit:
> 
> >There is no plan yet.  I would like to branch sometime very soon; does
> 
> I would like to bring back patches the MirOS Project (an OpenBSD
> derivate) uses to build binutils to the HEAD branch (mainline?).
> 
> Is there interest and what is the procedure? I'd suggest that I
> make small diffs (that would be about half a dozen), send them
> to the list and ask for testers on other OSes? I only have way
> to test them on MirOS/i386 (and later MirOS/powerpc and sparc)
> using a korn shell and BSD make, that's why it would probably
> have to be tested.

Yes, that's the right way to do it.  I don't much intend to see these
in 2.16, though.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Aaron,

> For i386 PE targets, there is an issue with weak symbol support.  Since
> 2.16 will be the first release where these "work," it would be nice if
> their semantics were fixed for the foreseeable future.

A good idea.

> Specifically, while the current PE weak symbol semantics are correct
> with respect to applicable standards and documentation, they are
> incompatible with ELF in one particular respect.  The feedback I have
> received indicates that this sort of compatibility may be important.
> See <http://sourceforge.net/mailarchive/message.php?msg_id=10854052> for
> details.
> 
> I'm waiting for feedback on the mingw-dvlpr list (or here).  If it seems
> the consensus is that this extension should be implemented, I'll submit
> a patch.  The latest I'd submit a patch would be on February 21.

Actually I think that you are pretty much the expert in this area.  So 
if you feel that this extension should be implemented then I am happy to 
review your patch and apply it.

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Anil,

> We are very keen to become maintainers for H8/300 target in Binutils. I would be grateful if you could tell me ( or give a link) which describes maintainer responsibilities. We will do our best to fulfill them. 

There is a lot of information about maintainership of GNU projects at 
this site:

http://www.gnu.org/prep/maintain/

The good news however is that for binutils being a maintainer of a port 
  to a particular target is lot simpler.  So instead take a look at this 
file:

   <binutils-sources>/binutils/MAINTAINERS

and in particular the section on maintainers.

So if you feel that you can work to improve the h8/300 port, review 
changes by other people to h8/300 specific files,  and watch for changes 
to the generic code that adversely affects the h8/300 port then you are 
suitable to be a maintainer fir the h8/300 port.

Cheers
   Nick

RE: Q: Estimated date for 2.16 release ?

[Anil Paranjape]

Hi Nick,

Thanks a lot for your positive reply.
We are very keen to become maintainers for H8/300 target in Binutils. I would be grateful if you could tell me ( or give a link) which describes maintainer responsibilities. We will do our best to fulfill them. 

Regards,
Anil Paranjpe
KPIT Cummins InfoSystems Ltd.
Pune, India

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users.
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 1, 2005.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com]
Sent: Monday, February 14, 2005 4:28 PM
To: Anil Paranjape
Cc: binutils@sources.redhat.com
Subject: Re: Q: Estimated date for 2.16 release ?


Hi Anil,

> We request you not to deprecate H8/300 target from Binutils since H8/300 is supported in GCC and will be supported in GDB as well.

Ok - we will not deprecate the code.

Are you offering to become a binutils maintainer for this code ?

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Aaron W. LaFramboise]

Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:

>>Is there any estimated date for the next Binutils formal release (version 
>>2.16) ?
>>We would like to plan our work accordingly.
> 
> There is no plan yet.  I would like to branch sometime very soon; does
> anyone know of issues that need to be resolved before the next release?

For i386 PE targets, there is an issue with weak symbol support.  Since
2.16 will be the first release where these "work," it would be nice if
their semantics were fixed for the foreseeable future.

Specifically, while the current PE weak symbol semantics are correct
with respect to applicable standards and documentation, they are
incompatible with ELF in one particular respect.  The feedback I have
received indicates that this sort of compatibility may be important.
See <http://sourceforge.net/mailarchive/message.php?msg_id=10854052> for
details.

I'm waiting for feedback on the mingw-dvlpr list (or here).  If it seems
the consensus is that this extension should be implemented, I'll submit
a patch.  The latest I'd submit a patch would be on February 21.


Aaron W. LaFramboise

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Anil,

> We request you not to deprecate H8/300 target from Binutils since H8/300 is supported in GCC and will be supported in GDB as well.

Ok - we will not deprecate the code.

Are you offering to become a binutils maintainer for this code ?

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Miles,

> Is there some kinda of "master list" of targets-in-danger-of-obsolescence?

Yes.  Well yes-ish.  There is a bit of code at the start of 
bfd/config.bfd that recognise targets that are proposed for 
obsolescence.  The idea is that if anybody uses these targets they will 
complain on the list and their status can be restored before the next 
branch is cut:

   case $targ in
    null)
       if test "x$enable_obsolete" != xyes; then
         echo "*** Configuration $targ is obsolete." >&2
         echo "*** Specify --enable-obsolete to build it anyway." >&2
         echo "*** Support will be REMOVED in the next major release of 
BINUTILS," >&2
         echo "*** unless a maintainer comes forward." >&2
         exit 1
       fi;;
   esac

Currently this list is empty because we are about to cut the 2.16 branch.

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Eric Botcazou]

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

> Fixed thusly.
>
>
> 	* ld-sparc/tlssunnopic32.rd: Adjust for .dynsym changes.
> 	* ld-sparc/tlssunpic32.rd: Likewise.

I forgot the following tweaks to the driver, that make it possible to run the 
tests on Solaris and prevent the 32-bit tests from being run on sparc64-elf.

Tested with a cross to all affected targets as well as natively on Solaris, 
applied as obvious.


	* ld-sparc/sparc-exp: Enable on Solaris.  Disable 32-bit tests
	on sparc64-elf.


-- 
Eric Botcazou

[-- Attachment #2: sparc_testsuite_driver.diff --]
[-- Type: text/x-diff, Size: 1024 bytes --]

Index: sparc.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-sparc/sparc.exp,v
retrieving revision 1.1
diff -u -r1.1 sparc.exp
--- sparc.exp	24 Jan 2003 23:44:45 -0000	1.1
+++ sparc.exp	14 Feb 2005 09:52:11 -0000
@@ -16,10 +16,11 @@
 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 #
 
-# Test i386 linking; all types of relocs.  This tests the assembler and
+# Test SPARC linking; all types of relocs.  This tests the assembler and
 # tools like objdump as well as the linker.
 
-if { !([istarget "sparc*-*-elf*"]		
+if { !([istarget "sparc*-*-elf*"]
+       || [istarget "sparc*-sun-solaris*"]
        || ([istarget "sparc*-*-linux*"]
 	   && ![istarget "*-*-*aout*"]
 	   && ![istarget "*-*-*oldld*"])) } {
@@ -84,5 +85,7 @@
      {{objdump -sj.debug_foobar tlsg64.sd}} "tlsg64"}
 }
 
-run_ld_link_tests $sparctests
+if { ![istarget "sparc64-*-elf*"] } {
+    run_ld_link_tests $sparctests
+}
 # run_ld_link_tests $sparc64tests

Re: Q: Estimated date for 2.16 release ?

[Miles Bader]

Is there some kinda of "master list" of targets-in-danger-of-obsolescence?

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: Q: Estimated date for 2.16 release ?

[Anil Paranjape]

Hi,

This mail is regarding discussion on possible removal of targets from  Binutils which are not supported in GCC and GDB. 
Please refer to following link,
http://sources.redhat.com/ml/binutils/2005-01/msg00517.html

Sincere efforts are going on to include H8/300 target back to GDB-6.4 by writing patch for new frame code support in GDB.
Please refer to following link,
http://sources.redhat.com/ml/gdb-patches/2005-02/msg00079.html

Mr. Yoshinori Sato has written a patch supporting new frame code in GDB for H8/300 target. He has also finished signing of copyright assignment with FSF. Now, H8/300 target will soon get included back into GDB-6.4 release.

We request you not to deprecate H8/300 target from Binutils since H8/300 is supported in GCC and will be supported in GDB as well.

KPIT Cummins is committed to support Renesas targets in GNU tools and is willing to take up any work regarding these targets.

Regards,
Anil Paranjpe
KPIT Cummins InfoSystems Ltd.
Pune, India

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Free download of GNU based tool-chains for Renesas' SH and H8 Series.
The following site also offers free technical support to its users.
Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 1, 2005.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Q: Estimated date for 2.16 release ?

[Eric Botcazou]

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

[Sorry for the delay]

> My understanding is that Eric fixed the bug and all that needs to be done
> is simply adjust the testcase expected results (after verifying linker
> output is correct) for the added .got STT_SECTION symbol etc.

Right, tlssunpic32.rd only needs to account for .got in .dynsym again, which 
essentially boiled down to shifting the dynamic indexes.

> The test that was failing before Eric's patch was not even adjusted for
> my .dynsym changes.

Right, tlssunnopic32.rd was out of sync for the section order, the contents 
of .dynsym and the type of TLS symbols (it was NOTYPE).

Fixed thusly.


	* ld-sparc/tlssunnopic32.rd: Adjust for .dynsym changes.
	* ld-sparc/tlssunpic32.rd: Likewise.


-- 
Eric Botcazou

[-- Attachment #2: tls_sparc_testsuite.diff --]
[-- Type: text/x-diff, Size: 7343 bytes --]

Index: tlssunnopic32.rd
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-sparc/tlssunnopic32.rd,v
retrieving revision 1.1
diff -u -r1.1 tlssunnopic32.rd
--- tlssunnopic32.rd	24 Jan 2003 23:44:45 -0000	1.1
+++ tlssunnopic32.rd	14 Feb 2005 00:01:16 -0000
@@ -15,11 +15,11 @@
  +\[ 3\] .dynstr +.*
  +\[ 4\] .rela.dyn +.*
  +\[ 5\] .text +PROGBITS +0+1000 0+1000 0+1000 0+ +AX +0 +0 4096
- +\[ 6\] .data +PROGBITS +0+12000 0+2000 0+ 0+ +WA +0 +0 4096
- +\[ 7\] .tbss +NOBITS +0+12000 0+2000 0+24 0+ WAT +0 +0 +4
- +\[ 8\] .dynamic +DYNAMIC +0+12000 0+2000 0+80 08 +WA +3 +0 +4
+ +\[ 6\] .tbss +NOBITS +0+12000 0+2000 0+24 0+ WAT +0 +0 +4
+ +\[ 7\] .dynamic +DYNAMIC +0+12000 0+2000 0+80 08 +WA +3 +0 +4
+ +\[ 8\] .got +PROGBITS +0+12080 0+2080 0+1c 04 +WA +0 +0 +4
  +\[ 9\] .plt +.*
- +\[10\] .got +PROGBITS +0+12080 0+2080 0+1c 04 +WA +0 +0 +4
+ +\[10\] .data +PROGBITS +0+13000 0+3000 0+ 0+ +WA +0 +0 4096
  +\[11\] .bss +.*
  +\[12\] .shstrtab +.*
  +\[13\] .symtab +.*
@@ -32,15 +32,15 @@
 Program Headers:
  +Type +Offset +VirtAddr +PhysAddr +FileSiz MemSiz +Flg Align
  +LOAD +0x0+ 0x0+ 0x0+ 0x0+2000 0x0+2000 R E 0x10000
- +LOAD +0x0+2000 0x0+12000 0x0+12000 0x0+9c 0x0+a0 RWE 0x10000
+ +LOAD +0x0+2000 0x0+12000 0x0+12000 0x0+1000 0x0+1000 RWE 0x10000
  +DYNAMIC +0x0+2000 0x0+12000 0x0+12000 0x0+80 0x0+80 RW +0x4
  +TLS +0x0+2000 0x0+12000 0x0+12000 0x0+ 0x0+24 R +0x4
 #...
 
 Relocation section '.rela.dyn' at offset 0x[0-9a-f]+ contains 12 entries:
  Offset +Info +Type +Sym. Value +Symbol's Name \+ Addend
-0+1004 +0+a09 R_SPARC_HI22 +0+12080 +\.got \+ 12080
-0+1008 +0+a0c R_SPARC_LO10 +0+12080 +\.got \+ 12080
+0+1004 +0+309 R_SPARC_HI22 +0+12080 +\.got \+ 12080
+0+1008 +0+30c R_SPARC_LO10 +0+12080 +\.got \+ 12080
 0+10dc +0+48 R_SPARC_TLS_LE_HIX22 +0+9
 0+10e0 +0+49 R_SPARC_TLS_LE_LOX10 +0+9
 0+10f8 +0+48 R_SPARC_TLS_LE_HIX22 +0+1c
@@ -49,31 +49,25 @@
 0+12088 +0+4e R_SPARC_TLS_TPOFF32 +0+4
 0+12094 +0+4e R_SPARC_TLS_TPOFF32 +0+14
 0+12098 +0+4e R_SPARC_TLS_TPOFF32 +0+18
-0+1208c +0+f4e R_SPARC_TLS_TPOFF32 +0+ +sg1 \+ 0
-0+12090 +0+114e R_SPARC_TLS_TPOFF32 +0+ +sg2 \+ 0
+0+1208c +0+94e R_SPARC_TLS_TPOFF32 +0+ +sg1 \+ 0
+0+12090 +0+b4e R_SPARC_TLS_TPOFF32 +0+ +sg2 \+ 0
 
-Symbol table '.dynsym' contains 20 entries:
+Symbol table '.dynsym' contains 14 entries:
  +Num: +Value +Size Type +Bind +Vis +Ndx Name
  +0: 0+ +0 NOTYPE +LOCAL +DEFAULT +UND *
- +1: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +1 *
- +2: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +2 *
- +3: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +3 *
- +4: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +4 *
- +5: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +5 *
- +6: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +6 *
- +7: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +7 *
- +8: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +8 *
- +9: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +9 *
- +10: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +10 *
- +11: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +11 *
- +12: 0+12000 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
- +13: 0+1000 +0 FUNC +GLOBAL DEFAULT +5 fn3
- +14: 0+12080 +0 OBJECT +GLOBAL DEFAULT +ABS _PROCEDURE_LINKAGE_TABLE_
- +15: 0+ +0 NOTYPE +GLOBAL DEFAULT +UND sg1
- +16: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS __bss_start
- +17: 0+ +0 NOTYPE +GLOBAL DEFAULT +UND sg2
- +18: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _edata
- +19: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _end
+ +1: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +5 *
+ +2: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +6 *
+ +3: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +8 *
+ +4: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +10 *
+ +5: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +11 *
+ +6: 0+12000 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
+ +7: 0+1000 +0 FUNC +GLOBAL DEFAULT +5 fn3
+ +8: [0-9a-f]+ +0 OBJECT +GLOBAL DEFAULT +ABS _PROCEDURE_LINKAGE_TABLE_
+ +9: 0+ +0 TLS +GLOBAL DEFAULT +UND sg1
+ +10: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS __bss_start
+ +11: 0+ +0 TLS +GLOBAL DEFAULT +UND sg2
+ +12: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _edata
+ +13: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _end
 
 Symbol table '.symtab' contains 33 entries:
  +Num: +Value +Size Type +Bind +Vis +Ndx Name
@@ -92,21 +86,21 @@
  +12: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +12 *
  +13: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +13 *
  +14: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +14 *
- +15: 0+ +0 TLS +LOCAL +DEFAULT +7 bl1
- +16: 0+4 +0 TLS +LOCAL +DEFAULT +7 bl2
- +17: 0+8 +0 TLS +LOCAL +DEFAULT +7 bl3
- +18: 0+c +0 TLS +LOCAL +DEFAULT +7 bl4
- +19: 0+10 +0 TLS +LOCAL +DEFAULT +7 bl5
- +20: 0+1c +0 TLS +LOCAL +HIDDEN +7 sh3
- +21: 0+20 +0 TLS +LOCAL +HIDDEN +7 sh4
- +22: 0+14 +0 TLS +LOCAL +HIDDEN +7 sh1
+ +15: 0+ +0 TLS +LOCAL +DEFAULT +6 bl1
+ +16: 0+4 +0 TLS +LOCAL +DEFAULT +6 bl2
+ +17: 0+8 +0 TLS +LOCAL +DEFAULT +6 bl3
+ +18: 0+c +0 TLS +LOCAL +DEFAULT +6 bl4
+ +19: 0+10 +0 TLS +LOCAL +DEFAULT +6 bl5
+ +20: 0+1c +0 TLS +LOCAL +HIDDEN +6 sh3
+ +21: 0+20 +0 TLS +LOCAL +HIDDEN +6 sh4
+ +22: 0+14 +0 TLS +LOCAL +HIDDEN +6 sh1
  +23: 0+12080 +0 OBJECT +LOCAL +HIDDEN +ABS _GLOBAL_OFFSET_TABLE_
- +24: 0+18 +0 TLS +LOCAL +HIDDEN +7 sh2
+ +24: 0+18 +0 TLS +LOCAL +HIDDEN +6 sh2
  +25: 0+12000 +0 OBJECT +GLOBAL DEFAULT +ABS _DYNAMIC
  +26: 0+1000 +0 FUNC +GLOBAL DEFAULT +5 fn3
- +27: 0+12080 +0 OBJECT +GLOBAL DEFAULT +ABS _PROCEDURE_LINKAGE_TABLE_
- +28: 0+ +0 NOTYPE +GLOBAL DEFAULT +UND sg1
+ +27: [0-9a-f]+ +0 OBJECT +GLOBAL DEFAULT +ABS _PROCEDURE_LINKAGE_TABLE_
+ +28: 0+ +0 TLS +GLOBAL DEFAULT +UND sg1
  +29: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS __bss_start
- +30: 0+ +0 NOTYPE +GLOBAL DEFAULT +UND sg2
+ +30: 0+ +0 TLS +GLOBAL DEFAULT +UND sg2
  +31: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _edata
  +32: [0-9a-f]+ +0 NOTYPE +GLOBAL DEFAULT +ABS _end
Index: tlssunpic32.rd
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-sparc/tlssunpic32.rd,v
retrieving revision 1.3
diff -u -r1.3 tlssunpic32.rd
--- tlssunpic32.rd	2 Nov 2004 05:40:05 -0000	1.3
+++ tlssunpic32.rd	14 Feb 2005 00:01:16 -0000
@@ -52,21 +52,22 @@
 0+12130 +0+4e R_SPARC_TLS_TPOFF32 +0+70
 0+12138 +0+4a R_SPARC_TLS_DTPMOD32 +0+
 0+12140 +0+4e R_SPARC_TLS_TPOFF32 +0+44
-0+12120 +0+a4e R_SPARC_TLS_TPOFF32 +0+10 +sg5 \+ 0
-0+12124 +0+d4a R_SPARC_TLS_DTPMOD32 +0+ +sg1 \+ 0
-0+12128 +0+d4c R_SPARC_TLS_DTPOFF32 +0+ +sg1 \+ 0
-0+12134 +0+104e R_SPARC_TLS_TPOFF32 +0+4 +sg2 \+ 0
+0+12120 +0+b4e R_SPARC_TLS_TPOFF32 +0+10 +sg5 \+ 0
+0+12124 +0+e4a R_SPARC_TLS_DTPMOD32 +0+ +sg1 \+ 0
+0+12128 +0+e4c R_SPARC_TLS_DTPOFF32 +0+ +sg1 \+ 0
+0+12134 +0+114e R_SPARC_TLS_TPOFF32 +0+4 +sg2 \+ 0
 
 Relocation section '.rela.plt' at offset 0x[0-9a-f]+ contains 1 entries:
  Offset +Info +Type +Sym. Value +Symbol's Name \+ Addend
-0+12174 +0+c15 R_SPARC_JMP_SLOT +0+ +__tls_get_addr \+ 0
+0+12174 +0+d15 R_SPARC_JMP_SLOT +0+ +__tls_get_addr \+ 0
 
-Symbol table '.dynsym' contains 21 entries:
+Symbol table '.dynsym' contains 22 entries:
  +Num: +Value +Size Type +Bind +Vis +Ndx Name
  +0: 0+ +0 NOTYPE +LOCAL +DEFAULT +UND *
  +[0-9]+: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +6 *
  +[0-9]+: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +7 *
  +[0-9]+: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +8 *
+ +[0-9]+: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +10 *
  +[0-9]+: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +12 *
  +[0-9]+: [0-9a-f]+ +0 SECTION LOCAL +DEFAULT +13 *
  +[0-9]+: 0+1c +0 TLS +GLOBAL DEFAULT +7 sg8

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

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

Hi Daniel,

>>I had a discussion with Alan Modra last week and we agreed that a more
>>aggressive target deprecation policy would be a good idea,

> Yes.  Someone should take charge of doing that, starting with removing
> the targets currently marked obsolete :-)

I have checked in the attached patch to do this.

Cheers
   Nick

bfd/ChangeLog
2005-01-31  Nick Clifton  <nickc@redhat.com>

	* confg.bfd: Make targets scheduled for obsoletion (m68k-lynxos,
	sparc-lynxos, vax-vms) be obsolete.

ld/ChangeLog
2005-01-31  Nick Clifton  <nickc@redhat.com>

	* configure.tgt: Remove obsolete targets m68k-lynxos and
	sparc-lynxos.

gas/ChangeLog
2005-01-31  Nick Clifton  <nickc@redhat.com>

	* configure.tgt: Remove obsolete targets m68k-lynxos, sparc-lynxos
	and vax-vms.

[-- Attachment #2: obsolete.patch --]
[-- Type: text/plain, Size: 3062 bytes --]

Index: bfd/config.bfd
===================================================================
RCS file: /cvs/src/src/bfd/config.bfd,v
retrieving revision 1.180
diff -c -3 -p -r1.180 config.bfd
*** bfd/config.bfd	6 Jan 2005 16:18:18 -0000	1.180
--- bfd/config.bfd	31 Jan 2005 17:07:46 -0000
*************** targ_underscore=no
*** 31,39 ****
  
  # Catch obsolete configurations.
  case $targ in
-  m68*-*-lynxos* | \
-  sparc-*-lynxos* | \
-  vax-*-vms* | \
   null)
      if test "x$enable_obsolete" != xyes; then
        echo "*** Configuration $targ is obsolete." >&2
--- 31,36 ----
*************** case $targ in
*** 45,50 ****
--- 42,50 ----
  esac
  
  case $targ in
+  m68*-*-lynxos* | \
+  sparc-*-lynxos* | \
+  vax-*-vms* | \
   arm-*-oabi | \
   thumb-*-oabi | \
   null)
Index: gas/configure.tgt
===================================================================
RCS file: /cvs/src/src/gas/configure.tgt,v
retrieving revision 1.2
diff -c -3 -p -r1.2 configure.tgt
*** gas/configure.tgt	6 Jan 2005 16:13:48 -0000	1.2
--- gas/configure.tgt	31 Jan 2005 17:07:48 -0000
*************** case ${generic_target} in
*** 268,274 ****
    m68k-*-linux-gnu*)			fmt=elf em=linux ;;
    m68k-*-uclinux*)			fmt=elf ;;
    m68k-*-gnu*)				fmt=elf ;;
-   m68k-*-lynxos*)			fmt=coff em=lynx ;;
    m68k-*-netbsdelf*)			fmt=elf em=nbsd ;;
    m68k-*-netbsd*)			fmt=aout em=nbsd bfd_gas=yes ;;
    m68k-*-openbsd*)			fmt=aout em=nbsd bfd_gas=yes ;;
--- 268,273 ----
*************** case ${generic_target} in
*** 371,377 ****
    sparc-*-coff)				fmt=coff ;;
    sparc-*-linux*aout*)			fmt=aout em=linux ;;
    sparc-*-linux-gnu*)			fmt=elf em=linux ;;
-   sparc-*-lynxos*)			fmt=coff em=lynx ;;
    sparc-fujitsu-none)			fmt=aout ;;
    sparc-*-elf)				fmt=elf ;;
    sparc-*-sysv4*)			fmt=elf ;;
--- 370,375 ----
*************** case ${generic_target} in
*** 401,407 ****
    vax-*-netbsd*)			fmt=aout em=nbsd ;;
    vax-*-bsd* | vax-*-ultrix*)		fmt=aout ;;
    vax-*-linux-gnu*)			fmt=elf em=linux bfd_gas=yes ;;
-   vax-*-vms)				fmt=vms ;;
  
    w65-*-*)				fmt=coff ;;
  
--- 399,404 ----
Index: ld/configure.tgt
===================================================================
RCS file: /cvs/src/src/ld/configure.tgt,v
retrieving revision 1.163
diff -c -3 -p -r1.163 configure.tgt
*** ld/configure.tgt	20 Jan 2005 19:37:49 -0000	1.163
--- ld/configure.tgt	31 Jan 2005 17:07:49 -0000
*************** sparc*-*-linux-gnu*)	targ_emul=elf32_spa
*** 76,82 ****
  			tdir_elf64_sparc=`echo ${targ_alias} | sed -e 's/32//'`
  			tdir_sun4=sparc-sun-sunos4
  			;;
- sparc*-*-lynxos*)	targ_emul=sparclynx ;;
  sparc64-*-netbsd* | sparc64-*-openbsd*)
  			targ_emul=elf64_sparc
  			targ_extra_emuls="elf32_sparc"
--- 76,81 ----
*************** m68k-*-linux-gnu*)	targ_emul=m68kelf
*** 379,385 ****
  			;;
  m68k-*-uclinux*)	targ_emul=m68kelf ;;
  m68*-*-gnu*)		targ_emul=m68kelf ;;
- m68*-*-lynxos*)		targ_emul=m68klynx ;;
  m68*-*-netbsd*4k*)	targ_emul=m68k4knbsd
  			targ_extra_emuls="m68knbsd m68kelfnbsd" ;;
  m68*-*-netbsdelf*)	targ_emul=m68kelfnbsd
--- 378,383 ----

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi Daniel,

>>Is there any estimated date for the next Binutils formal release (version 
>>2.16) ?
>>We would like to plan our work accordingly.

> There is no plan yet.  I would like to branch sometime very soon; 

Excellent - I whole heartedly endorse this.

> does anyone know of issues that need to be resolved before the next release?

Would it be possible to have a regular post to the list, eg weekly, of 
bugs that need to be fixed before you are ready to branch ?  This could 
act as an incentive to get them fixed :-)

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Nick Clifton]

Hi,

> Will 2.16 implement the CORRECT BSDI/ELF patch that I submitted?

Possibly - but only if we receive a proper submission in time.  In 
particular we would need:

  1. A copyright assignment to the FSF from the copyright holder(s) of 
the patch.  Without this we cannot accept the patch.  This is a proper 
legal document and there is a procedure to follow in order to obtain it, 
so if you want to apply for one please let me know.

2. A tidied up patch.  This is mostly laziness on my part, but I would 
like to have one email that is just the patch, fully tested to make sure 
that it applied and builds a toolchain that works, and which also:

   * Follows the GNU Coding standards.
   * Adds an entry to the NEWS files in the appropriate subdirectory(s) 
announcing the availability of a new port.

3. ChangeLog entries for all of the ChangeLogs in the directories 
affected by the patch.  With real name(s) for the submitters please. 
"The Doctor" is a nice alias but we prefer to deal with real people.

Cheers
   Nick

Re: Q: Estimated date for 2.16 release ?

[Hans-Peter Nilsson]

On Thu, 27 Jan 2005, Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 10:56:30AM -0500, Hans-Peter Nilsson wrote:
> > On Thu, 27 Jan 2005, Ian Lance Taylor wrote:
> > > Hans-Peter Nilsson <hp@bitrange.com> writes:
> > > > BTW, was the intl/ directory about to be added to binutils?
> > > > Maybe that and the fallout should be done before the release.
> > > > Or maybe better done after branching?
> > > The binutils releases already have an intl directory, don't they?
> > > They used to, and it seems to me that they still do.
> >
> > Oh right you are, problem misdiagnosed.  Still a problem,
> > though, and one that would be good to fix before the next
> > release.
>
> It's more complicated than you think :-)

Uh, remind me: what did I think?  (I made no claim about
simplicity above. ;-)

FWIW, one workaround is to remove the intl directory from the
combined sources.  Perhaps better than upgrading binutils to
autoconf 2.59 at this time (which would seem necessary in order
to sync the intl machinery).

Anyway, I've seen a problem with the stabs linker-warning
machinery (see libgloss/libnosys/warning.h) and a.out; there's a
SEGV which valgrind says is an invalid access, after allocated
memory.  Valgrind also changes the behavior and instead of the
linker warnings, the symbols are undefined.  PR and testcase
later.

brgds, H-P

Re: Q: Estimated date for 2.16 release ?

[Ben Elliston]

Daniel Jacobowitz <drow@false.org> writes:

> > Have the simple installation problems from 2.15 been worked out?
> 
> Could you remind me which specific problems you are referring to?

I recall a straightforward bug that affected all Solaris users, at
least.  Perhaps there are others.

Ben

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Mon, Jan 31, 2005 at 11:28:25AM +1100, Ben Elliston wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > There is no plan yet.  I would like to branch sometime very soon;
> > does anyone know of issues that need to be resolved before the next
> > release?
> 
> Also, would it be worth having a discussion here about which targets
> should be marked obsolete in 2.16 (if that hasn't happened already),
> for possible removal in the following binutils release?
> 
> I had a discussion with Alan Modra last week and we agreed that a more
> aggressive target deprecation policy would be a good idea,
> particularly for targets that are no longer supported by GCC and/or
> GDB.

Yes.  Someone should take charge of doing that, starting with removing
the targets currently marked obsolete :-)

-- 
Daniel Jacobowitz

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Mon, Jan 31, 2005 at 11:26:29AM +1100, Ben Elliston wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > There is no plan yet.  I would like to branch sometime very soon;
> > does anyone know of issues that need to be resolved before the next
> > release?
> 
> Have the simple installation problems from 2.15 been worked out?

Could you remind me which specific problems you are referring to?

-- 
Daniel Jacobowitz

Re: Q: Estimated date for 2.16 release ?

[Ben Elliston]

Daniel Jacobowitz <drow@false.org> writes:

> There is no plan yet.  I would like to branch sometime very soon;
> does anyone know of issues that need to be resolved before the next
> release?

Also, would it be worth having a discussion here about which targets
should be marked obsolete in 2.16 (if that hasn't happened already),
for possible removal in the following binutils release?

I had a discussion with Alan Modra last week and we agreed that a more
aggressive target deprecation policy would be a good idea,
particularly for targets that are no longer supported by GCC and/or
GDB.

Cheers, Ben

Re: Q: Estimated date for 2.16 release ?

[Ben Elliston]

Daniel Jacobowitz <drow@false.org> writes:

> There is no plan yet.  I would like to branch sometime very soon;
> does anyone know of issues that need to be resolved before the next
> release?

Have the simple installation problems from 2.15 been worked out?

Ben

Re: Q: Estimated date for 2.16 release ?

[The Doctor]

On Thu, Jan 27, 2005 at 09:00:10AM -0500, Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:
> > Hi Nick,
> > 
> > Is there any estimated date for the next Binutils formal release (version 
> > 2.16) ?
> > We would like to plan our work accordingly.
> 
> There is no plan yet.  I would like to branch sometime very soon; does
> anyone know of issues that need to be resolved before the next release?
> 
> -- 
> Daniel Jacobowitz

Will 2.16 implement the CORRECT BSDI/ELF patch that I submitted?

-- 
Member - Liberal International	
This is doctor@nl2k.ab.ca	Ici doctor@nl2k.ab.ca
God Queen and country! Beware Anti-Christ rising!
Birthdate: 29 Jan 1969 Redhill, Surrey, England, UK

Re: Q: Estimated date for 2.16 release ?

[Thorsten Glaser]

Daniel Jacobowitz dixit:

>There is no plan yet.  I would like to branch sometime very soon; does

I would like to bring back patches the MirOS Project (an OpenBSD
derivate) uses to build binutils to the HEAD branch (mainline?).

Is there interest and what is the procedure? I'd suggest that I
make small diffs (that would be about half a dozen), send them
to the list and ask for testers on other OSes? I only have way
to test them on MirOS/i386 (and later MirOS/powerpc and sparc)
using a korn shell and BSD make, that's why it would probably
have to be tested.

Thanks in advance,
//mirabile

PS: I've got the (c) forms already signed.

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Thu, Jan 27, 2005 at 10:56:30AM -0500, Hans-Peter Nilsson wrote:
> On Thu, 27 Jan 2005, Ian Lance Taylor wrote:
> > Hans-Peter Nilsson <hp@bitrange.com> writes:
> >
> > > BTW, was the intl/ directory about to be added to binutils?
> > > Maybe that and the fallout should be done before the release.
> > > Or maybe better done after branching?
> >
> > The binutils releases already have an intl directory, don't they?
> > They used to, and it seems to me that they still do.
> 
> Oh right you are, problem misdiagnosed.  Still a problem,
> though, and one that would be good to fix before the next
> release.

It's more complicated than you think :-)  src/ and gcc/ have different
versions of intl, and more importantly, different versions of the intl/
m4 glue.  The only thing that would reliably fix this is using the same
version for both, and since this does not affect binutils release
tarballs, let's not touch it till after 2.16.

-- 
Daniel Jacobowitz

Re: Q: Estimated date for 2.16 release ?

[Hans-Peter Nilsson]

On Thu, 27 Jan 2005, Ian Lance Taylor wrote:
> Hans-Peter Nilsson <hp@bitrange.com> writes:
>
> > BTW, was the intl/ directory about to be added to binutils?
> > Maybe that and the fallout should be done before the release.
> > Or maybe better done after branching?
>
> The binutils releases already have an intl directory, don't they?
> They used to, and it seems to me that they still do.

Oh right you are, problem misdiagnosed.  Still a problem,
though, and one that would be good to fix before the next
release.

brgds, H-P

Re: Q: Estimated date for 2.16 release ?

[Ian Lance Taylor]

Hans-Peter Nilsson <hp@bitrange.com> writes:

> BTW, was the intl/ directory about to be added to binutils?
> Maybe that and the fallout should be done before the release.
> Or maybe better done after branching?

The binutils releases already have an intl directory, don't they?
They used to, and it seems to me that they still do.

Ian

Re: Q: Estimated date for 2.16 release ?

[Hans-Peter Nilsson]

On Thu, 27 Jan 2005, Joel Sherrill <joel@OARcorp.com> wrote:
> http://sources.redhat.com/ml/binutils/2004-03/msg00489.html
>
> Eric Norum (cc'ed) recently narrowed it down to this construct:
>
> =============================================================
> A little poking around reveals that it's the lines like:
>
> _RamBase = DEFINED(_RamBase) ? _RamBase : 0x0;
> _RamSize = DEFINED(_RamSize) ? _RamSize : 0x7f0000;
> _HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0;   /* 0x20000;*/
> _StackSize = DEFINED(_StackSize) ? _StackSize : 1M; /* 0x2000;*/
>
> that are killing ld.
> ==============================================================
>
> Does this sound familiar?

Yes. :-(  The semantics of DEFINED has changed.  IIRC, my patch
to announce that in ld/NEWS before 2.15 received no comments.
The usage above should still work, though.

Can you open a PR with binutils-self-contained (only assembly
files, no C or objects) test-case?  Maybe all was at the URL
above, but I don't see the ld command line.  Still, please open
a PR.

brgds, H-P

Re: Q: Estimated date for 2.16 release ?

[Jakub Jelinek]

On Thu, Jan 27, 2005 at 03:07:42PM +0100, Christian Joensson wrote:
> On Thu, 27 Jan 2005 09:00:10 -0500, Daniel Jacobowitz <drow@false.org> wrote:
> > On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:
> > > Hi Nick,
> > >
> > > Is there any estimated date for the next Binutils formal release (version
> > > 2.16) ?
> > > We would like to plan our work accordingly.
> > 
> > There is no plan yet.  I would like to branch sometime very soon; does
> > anyone know of issues that need to be resolved before the next release?
> 
> may I humbly ask for help with
> 
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=171 

My understanding is that Eric fixed the bug and all that needs to be done
is simply adjust the testcase expected results (after verifying linker
output is correct) for the added .got STT_SECTION symbol etc.
The test that was failing before Eric's patch was not even adjusted for
my .dynsym changes.

	Jakub

Re: Q: Estimated date for 2.16 release ?

[Hans-Peter Nilsson]

On Thu, 27 Jan 2005, Daniel Jacobowitz wrote:
> does
> anyone know of issues that need to be resolved before the next release?

Adding @INTLLIBS@ to the link lines so solaris (etc)
gcc+binutils combined builds have a better chance of succeeding.
Maybe I should open a binutils PR...  See gcc.gnu.org/PR19468.

BTW, was the intl/ directory about to be added to binutils?
Maybe that and the fallout should be done before the release.
Or maybe better done after branching?

brgds, H-P

Re: Q: Estimated date for 2.16 release ?

[Joel Sherrill <joel@OARcorp.com>]

Daniel Jacobowitz wrote:
> On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:
> 
>>Hi Nick,
>>
>>Is there any estimated date for the next Binutils formal release (version 
>>2.16) ?
>>We would like to plan our work accordingly.
> 
> 
> There is no plan yet.  I would like to branch sometime very soon; does
> anyone know of issues that need to be resolved before the next release?

With gcc 4.x coming, we have noticed that the problem Ralf
reported here happens on multiple targets.  I don't know
if it was ever addressed or not.

http://sources.redhat.com/ml/binutils/2004-03/msg00489.html

Eric Norum (cc'ed) recently narrowed it down to this construct:

=============================================================
A little poking around reveals that it's the lines like:

_RamBase = DEFINED(_RamBase) ? _RamBase : 0x0;
_RamSize = DEFINED(_RamSize) ? _RamSize : 0x7f0000;
_HeapSize = DEFINED(_HeapSize) ? _HeapSize : 0;   /* 0x20000;*/
_StackSize = DEFINED(_StackSize) ? _StackSize : 1M; /* 0x2000;*/

that are killing ld.
==============================================================

Does this sound familiar?

-- 
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: Q: Estimated date for 2.16 release ?

[Eric Botcazou]

> may I humbly ask for help with
>
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=171

IMHO mixing TLS, -fno-pic and -shared is really asking for troubles. :-)

I plan on revisiting SPARC TLS support (especially 64-bit) in the near future, 
but after 2.16 has branched.

-- 
Eric Botcazou

Re: Q: Estimated date for 2.16 release ?

[Christian Joensson]

On Thu, 27 Jan 2005 09:00:10 -0500, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:
> > Hi Nick,
> >
> > Is there any estimated date for the next Binutils formal release (version
> > 2.16) ?
> > We would like to plan our work accordingly.
> 
> There is no plan yet.  I would like to branch sometime very soon; does
> anyone know of issues that need to be resolved before the next release?

may I humbly ask for help with

http://sources.redhat.com/bugzilla/show_bug.cgi?id=171 

-- 
Cheers,

/ChJ

Re: Q: Estimated date for 2.16 release ?

[Daniel Jacobowitz]

On Thu, Jan 27, 2005 at 03:40:59PM +0200, Tomer Levi wrote:
> Hi Nick,
> 
> Is there any estimated date for the next Binutils formal release (version 
> 2.16) ?
> We would like to plan our work accordingly.

There is no plan yet.  I would like to branch sometime very soon; does
anyone know of issues that need to be resolved before the next release?

-- 
Daniel Jacobowitz

Q: Estimated date for 2.16 release ?

[Tomer Levi]

Hi Nick,

Is there any estimated date for the next Binutils formal release (version 
2.16) ?
We would like to plan our work accordingly.
Thanks.

Regards,
      Tomer Levi

Software Engineer                          phone: +972-9-9702-067
National Semiconductor               fax:        +972-9-9702-001
Hasadnaot Str. 8                              mailto:Tomer.Levi@nsc.com
46130 Herzlia B, Israel                   internet: http://www.nsc.com