An egcs 1.1.2 patch for Linux/Alpha

An egcs 1.1.2 patch for Linux/Alpha

[H.J. Lu]

>   > 1. Better support for Linux/Alpha. It is just one line change:
>   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
>   >        * ginclude/va-alpha.h (va_list): Use a typedef, not a define.
> Submit it.
> 

I was told it might need another patch from Richard to get it to
work on OSF/Alpha. But I have no way to tell.


H.J.
---
Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>

	* ginclude/va-alpha.h (va_list): Use a typedef, not a define.

--- /home/work/misc/gnu/import/egcs/gcc/ginclude/va-alpha.h	Mon Aug 11 08:58:05 1997
+++ ginclude/va-alpha.h	Fri Jan 15 10:23:57 1999
@@ -28,8 +28,8 @@
 /* If this is for internal libc use, don't define anything but
    __gnuc_va_list.  */
 #if defined (_STDARG_H) || defined (_VARARGS_H)
+typedef __gnuc_va_list va_list;
 
-#define va_list __gnuc_va_list
 #define _VA_LIST
 #define _VA_LIST_
 

A Linux cross-compile patch

[H.J. Lu]

>   > 4. Better support for cross-compile. I fixed a bug you may only see
>   > when you do cross-compile from one Linux to another Linux. It is in
>   > the mainline now. But I need it for egcs 1.1.2.
> Again, without a patch I can't comment.

http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00280.html


H.J.

A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
>   > 12. Fix libio for libc 5.
> Can't comment without a patch.

http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html

You can see how old that patch is.


H.J.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

> >   > 12. Fix libio for libc 5.
> > Can't comment without a patch.
> 
> http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> 
> You can see how old that patch is.

This one looks low-risk (it only makes some symbols weak).  It seems
there's no risk of it destabilizing 1.1.2.

Of course it uses #pragma weak so if the rule now is to use attributes
instead, I guess this patch must be adjusted.

Re: An egcs 1.1.2 patch for Linux/Alpha

[Richard Henderson]

On Mon, Feb 22, 1999 at 12:15:16PM -0800, H.J. Lu wrote:
> I was told it might need another patch from Richard to get it to
> work on OSF/Alpha. But I have no way to tell.

Thu Sep  3 00:23:21 1998  Richard Henderson  <rth@cygnus.com>

        * ginclude/va-alpha.h: Protect entire second portion of the
        file against double inclusion.

Mon Aug 31 13:57:55 1998  Richard Henderson  <rth@cygnus.com>

        * alpha/va_list.h: New file.
        * alpha/x-alpha (EXTRA_HEADERS): New.  Add va_list.h.


r~

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> 
> > >   > 12. Fix libio for libc 5.
> > > Can't comment without a patch.
> > 
> > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> > 
> > You can see how old that patch is.
> 
> This one looks low-risk (it only makes some symbols weak).  It seems
> there's no risk of it destabilizing 1.1.2.
> 
> Of course it uses #pragma weak so if the rule now is to use attributes
> instead, I guess this patch must be adjusted.
> 

What is the attribute format for

#pragma weak old = new

Should we have a central location for it? If we do, I can also fix libobjc.
We should move those weak stuffs out of gthr-*. Many other places need the same
information also.


-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Robert Lipe]

> > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> 
> This one looks low-risk (it only makes some symbols weak).  It seems
> there's no risk of it destabilizing 1.1.2.

Right now, we're chasing a problem regarding the interaction of weak and
global symbols on some targets.  It's most often triggered by templates,
but I think that's only becuase that's our number one producer of weak
syms right now.

RJL

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> > 
> > This one looks low-risk (it only makes some symbols weak).  It seems
> > there's no risk of it destabilizing 1.1.2.
> 
> Right now, we're chasing a problem regarding the interaction of weak and
> global symbols on some targets.  It's most often triggered by templates,
> but I think that's only becuase that's our number one producer of weak
> syms right now.
> 

My libio patch will only affect systems which define both
_G_STDIO_USES_LIBIO and _G_HAVE_WEAK_SYMBOL. I blieve only
Linux does that.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux cross-compile patch

[Jeffrey A Law]

  In message < m10F1nl-000390C@ocean.lucon.org >you write:
  > >   > 4. Better support for cross-compile. I fixed a bug you may only see
  > >   > when you do cross-compile from one Linux to another Linux. It is in
  > >   > the mainline now. But I need it for egcs 1.1.2.
  > > Again, without a patch I can't comment.
  > 
  > http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00280.html
Note this is the first time as far as I know that you've mentioned this
patch was important for egcs-1.1.2.

It would avoid a lot of headaches in the future if you would indicate
that a patch is important for a minor release and way.

In many ways, this is no different than explaining the technical details
behind a patch -- when you leave out critical information I have to make
decisions based on my own best judgement.  Sometimes that judgement is wrong,
or does not parallel your own ideas.  Far better for you to be explicit about
this stuff and avoid the problems and wasted time in the first place.

jeff

Re: An egcs 1.1.2 patch for Linux/Alpha

[Jeffrey A Law]

  In message < m10F1l6-000390C@ocean.lucon.org >you write:
  > >   > 1. Better support for Linux/Alpha. It is just one line change:
  > >   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
  > >   >        * ginclude/va-alpha.h (va_list): Use a typedef, not a define.
  > > Submit it.
  > > 
  > 
  > I was told it might need another patch from Richard to get it to
  > work on OSF/Alpha. But I have no way to tell.
  > 
  > 
  > H.J.
  > ---
  > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
  > 
  > 	* ginclude/va-alpha.h (va_list): Use a typedef, not a define.
I've applied this along with Richard's patches.

Note carefully that had other folks not pointed out the need for Richard's
patch we could have totally busted the alpha-dec-osf* port.

When you submit patches to a release branch, you need try harder to make
sure they will not break other ports.  It is *critical* that a minor release
not take a step backwards like that.


Thanks,
jeff

Re: An egcs 1.1.2 patch for Linux/Alpha

[H.J. Lu]

> 
> 
> 
>   In message < m10F1l6-000390C@ocean.lucon.org >you write:
>   > >   > 1. Better support for Linux/Alpha. It is just one line change:
>   > >   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
>   > >   >        * ginclude/va-alpha.h (va_list): Use a typedef, not a define.
>   > > Submit it.
>   > > 
>   > 
>   > I was told it might need another patch from Richard to get it to
>   > work on OSF/Alpha. But I have no way to tell.
>   > 
>   > 
>   > H.J.
>   > ---
>   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
>   > 
>   > 	* ginclude/va-alpha.h (va_list): Use a typedef, not a define.
> I've applied this along with Richard's patches.
> 

Thanks.

> Note carefully that had other folks not pointed out the need for Richard's
> patch we could have totally busted the alpha-dec-osf* port.
> 
> When you submit patches to a release branch, you need try harder to make
> sure they will not break other ports.  It is *critical* that a minor release
> not take a step backwards like that.
> 

I don't have any OSF/Alpha machines. I need help from others.


-- 
H.J. Lu (hjl@gnu.org)

Re: An egcs 1.1.2 patch for Linux/Alpha

[Joe Buck]

Jeff writes:

> When you submit patches to a release branch, you need try harder to make
> sure they will not break other ports.  It is *critical* that a minor release
> not take a step backwards like that.

In practice, the submitter may not be able to know this in all cases, but
may still have a strong belief that a patch is needed to fix a problem
that is found at the last minute.

The risk is largest for patches that are proposed for the release branch
but have never been in the mainline.  But the case you're talking about here
is interesting because HJ's patch had been in the mainline, together with
Richard's patches to fix HJ's patches.  But HJ didn't seem aware of that.
We don't really have a system to manage this kind of dependency.

In this case, HJ knew he put in a fix to a problem, and knew it had been
checked in a while ago (so it is reasonable for him to think it was a safe
and tested patch), but there wasn't an easy way to "cross-reference"
the fact that it needed later fixes.  I don't know if there's a simple
way to keep better track of these things or not.

Re: An egcs 1.1.2 patch for Linux/Alpha

[Jeffrey A Law]

  In message < 199902231750.JAA04017@atrus.synopsys.com >you write:
  > In practice, the submitter may not be able to know this in all cases, but
  > may still have a strong belief that a patch is needed to fix a problem
  > that is found at the last minute.
Certainly.  But I think the submitter needs to at least check on this kind
of stuff.  A simple walk through the ChangeLog or the CVS repo looking for
additional changs to the same file and/or function is not too much to task
IMHO.

I'll note this is precisely what other contributors have done when submitting
old patches from the mainline sources to the branch, or what I do when picking
up an old patch from the mainline tree.  It's not terribly difficult to catch
obvious dependencies this way.  It's by no means foolproof, but it's better
than submitting a patch without any checking at all!

Why can't HJ do this like other folks?  Only caring about Linux is not an
excuse for not doing this kind of research for a patch.




  > In this case, HJ knew he put in a fix to a problem, and knew it had been
  > checked in a while ago (so it is reasonable for him to think it was a safe
  > and tested patch), but there wasn't an easy way to "cross-reference"
  > the fact that it needed later fixes.  I don't know if there's a simple
  > way to keep better track of these things or not.
There is no good cross-referencing for this kind of stuff (you can bet we've
been fighting this issue internally at Cygnus for a while).  However, ChangeLog
scanning will usually expose obvious dependencies or at least give a list of
changes someone more qualified needs to look at when evaluating a release
branch patch.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10F2Hp-000390C@ocean.lucon.org >you write:
  > > 
  > > 
  > > > >   > 12. Fix libio for libc 5.
  > > > > Can't comment without a patch.
  > > > 
  > > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
  > > > 
  > > > You can see how old that patch is.
  > > 
  > > This one looks low-risk (it only makes some symbols weak).  It seems
  > > there's no risk of it destabilizing 1.1.2.
  > > 
  > > Of course it uses #pragma weak so if the rule now is to use attributes
  > > instead, I guess this patch must be adjusted.
  > > 
  > 
  > What is the attribute format for
  > 
  > #pragma weak old = new
From the manual:
@cindex @code{alias} attribute
The @code{alias} attribute causes the declaration to be emitted as an
alias for another symbol, which must be specified.  For instance,

@smallexample
void __f () @{ /* do something */; @}
void f () __attribute__ ((weak, alias ("__f")));
@end smallexample

declares @samp{f} to be a weak alias for @samp{__f}.  In C++, the
mangled name for the target must be used.

Sounds like we need TARGET_ATTRIBUTE_WEAK_ALIAS

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10F2Hp-000390C@ocean.lucon.org >you write:
  > Should we have a central location for it? If we do, I can also fix libobjc.
  > We should move those weak stuffs out of gthr-*. Many other places need the 
  > same information also.
BTW, I'm not sure if we have a common location where we can add a weak-alias
attribute definition for use by target libraries outside of the gcc
subdirectory.


jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

>   > > 
>   > > > >   > 12. Fix libio for libc 5.
>   > > > > Can't comment without a patch.
>   > > > 
>   > > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
>   > > > 
>   > > > You can see how old that patch is.
>   > > 
>   > > This one looks low-risk (it only makes some symbols weak).  It seems
>   > > there's no risk of it destabilizing 1.1.2.
>   > > 
>   > > Of course it uses #pragma weak so if the rule now is to use attributes
>   > > instead, I guess this patch must be adjusted.
>   > > 
>   > 
>   > What is the attribute format for
>   > 
>   > #pragma weak old = new
> >From the manual:
> @cindex @code{alias} attribute
> The @code{alias} attribute causes the declaration to be emitted as an
> alias for another symbol, which must be specified.  For instance,
> 
> @smallexample
> void __f () @{ /* do something */; @}
> void f () __attribute__ ((weak, alias ("__f")));
> @end smallexample
> 
> declares @samp{f} to be a weak alias for @samp{__f}.  In C++, the
> mangled name for the target must be used.
> 
> Sounds like we need TARGET_ATTRIBUTE_WEAK_ALIAS
> 

Well, it seems a mess to me. We need TARGET_ATTRIBUTE_WEAK and
TARGET_ATTRIBUTE_WEAK_ALIAS for the target libraries. They
should be shared between gcc and libraries. There is a include
directory. Should I put a "runtime.h" there and put the weak
definitions in it? Also, somehow we need to make the target
runtime information available to libraries. Right now only gcc
knows it. Maybe it can be done for egcs 1.2.

As for libio, Ulrich, are you still maintaining libio in egcs?
Can you take a look at my libio patch? I don't want to spend my
time on it without your input first.

Thanks.



-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> As for libio, Ulrich, are you still maintaining libio in egcs?
> Can you take a look at my libio patch? I don't want to spend my
> time on it without your input first.

I can take a look but I don't know whether I have the time today.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10G46Y-000390C@ocean.lucon.org >you write:
  > Well, it seems a mess to me. We need TARGET_ATTRIBUTE_WEAK and
  > TARGET_ATTRIBUTE_WEAK_ALIAS for the target libraries
I don't this as a major problem.  What's the big deal?

  > They should be shared between gcc and libraries.
At some point, yes.  I don't think that needs to be a requirement today.

  > There is a include directory.
  > Should I put a "runtime.h" there and put the weak
  > definitions in it?
Let's not tackle this right now.  I'd like to get egcs-1.1.2 unstuck and out
the door.

Longer term, I can see having some file in libiberty which defines these
kinds of things for the host & target.

  > As for libio, Ulrich, are you still maintaining libio in egcs?
  > Can you take a look at my libio patch? I don't want to spend my
  > time on it without your input first.
HJ, please use the attribute like I have requested.  attributes are the GNU
standard, not pragmas.  Please use the attribute syntax.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

>   > Can you take a look at my libio patch? I don't want to spend my
>   > time on it without your input first.
> HJ, please use the attribute like I have requested.  attributes are the GNU
> standard, not pragmas.  Please use the attribute syntax.
> 

egcs is not the only place where libio is used and libio doesn't use
attribute for weak. If Ulrich is still maintaining libio in egcs, I'd
like to hear what he has to say.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10G4vU-000390C@ocean.lucon.org >you write:
  > >   > Can you take a look at my libio patch? I don't want to spend my
  > >   > time on it without your input first.
  > > HJ, please use the attribute like I have requested.  attributes are the G
  > NU
  > > standard, not pragmas.  Please use the attribute syntax.
  > > 
  > 
  > egcs is not the only place where libio is used and libio doesn't use
  > attribute for weak. If Ulrich is still maintaining libio in egcs, I'd
  > like to hear what he has to say.
But libio is a GNU package and is compiled by GNU compilers.

Use the attribute syntax please.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

>   > > > >   > 12. Fix libio for libc 5.
>   > > > > Can't comment without a patch.
>   > > > 
>   > > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
>   > > > 
>   > > > You can see how old that patch is.
>   > > 
>   > > This one looks low-risk (it only makes some symbols weak).  It seems
>   > > there's no risk of it destabilizing 1.1.2.
>   > > 
>   > > Of course it uses #pragma weak so if the rule now is to use attributes
>   > > instead, I guess this patch must be adjusted.
>   > > 
>   > 

Here is a libio patch for libc 5 using __attribute__ instead of pragma.
It is totally untested since I no longer have libc 5 machine. Someone
should check if it compiles and runs on libc 5.

BTW, pragma is in the current libio. I have to take some of them out
for __attribute__.

Thanks.


----
Thu Feb 25 12:17:52 1998  H.J. Lu  (hjl@gnu.org)

	* config/linuxlibc1.mt (MT_CFLAGS): Add -D_G_STDIO_USES_LIBIO
	-D_G_HAVE_WEAK_SYMBOL.

	* genops.c: Add the proper weak alias if _G_STDIO_USES_LIBIO
	and _G_HAVE_WEAK_SYMBOL are defined.
	* iofclose.c: Likewise.
	* iofeof.c: Likewise.
	* ioferror.c: Likewise.
	* iogetc.c: Likewise.
	* ioputc.c: Likewise.
	* iovsprintf.c: Likewise.
	* iovsscanf.c: Likewise.

--- ../../../import/egcs-1.1.x/egcs/libio/config/linuxlibc1.mt	Tue Feb 17 12:54:12 1998
+++ config/linuxlibc1.mt	Sat Feb  6 15:04:17 1999
@@ -23,4 +23,4 @@ USER_INCLUDES=PlotFile.h SFile.h builtin
 	streambuf.h strfile.h strstream.h libio.h
 
 # A bad kludge
-MT_CFLAGS=-D_G_HAVE_MMAP
+MT_CFLAGS=-D_G_HAVE_MMAP -D_G_STDIO_USES_LIBIO -D_G_HAVE_WEAK_SYMBOL
--- ../../../import/egcs-1.1.x/egcs/libio/./genops.c	Mon Jun  8 02:50:20 1998
+++ ./genops.c	Thu Feb 25 12:05:49 1999
@@ -937,6 +937,8 @@ __io_defs io_defs__;
 
 #ifdef weak_alias
 weak_alias (_IO_cleanup, _cleanup)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+void _cleanup () __attribute__ ((weak, "_IO_cleanup"));
 #endif
 
 #ifdef text_set_element
--- ../../../import/egcs-1.1.x/egcs/libio/./iofclose.c	Thu Oct 16 08:30:23 1997
+++ ./iofclose.c	Thu Feb 25 12:07:15 1999
@@ -55,8 +55,6 @@ _IO_fclose (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_fclose, fclose)
-#else
-#ifdef __linux__
-#pragma weak fclose = _IO_fclose
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int fclose (_IO_FILE *) __attribute__ ((weak, "_IO_fclose"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iofeof.c	Sat Sep  6 00:42:56 1997
+++ ./iofeof.c	Thu Feb 25 12:07:43 1999
@@ -40,4 +40,6 @@ _IO_feof (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_feof, feof)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int feof (_IO_FILE *) __attribute__ ((weak, "_IO_feof"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioferror.c	Sat Sep  6 00:42:57 1997
+++ ./ioferror.c	Thu Feb 25 12:08:10 1999
@@ -40,4 +40,6 @@ _IO_ferror (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_ferror, ferror)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int ferror (_IO_FILE *) __attribute__ ((weak, "_IO_ferror"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iogetc.c	Sat Sep  6 00:43:15 1997
+++ ./iogetc.c	Thu Feb 25 12:08:53 1999
@@ -45,4 +45,6 @@ _IO_getc (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_getc, getc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int getc (_IO_FILE *) __attribute__ ((weak, "_IO_getc"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioputc.c	Sat Sep  6 00:43:25 1997
+++ ./ioputc.c	Thu Feb 25 12:09:56 1999
@@ -39,4 +39,6 @@ _IO_putc (c, fp)
 
 #ifdef weak_alias
 weak_alias (_IO_putc, putc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int putc (int, _IO_FILE *) __attribute__ ((weak, "_IO_putc"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsprintf.c	Thu Oct 16 08:30:23 1997
+++ ./iovsprintf.c	Thu Feb 25 12:10:47 1999
@@ -54,8 +54,7 @@ _IO_vsprintf (string, format, args)
 
 #ifdef weak_alias
 weak_alias (_IO_vsprintf, vsprintf)
-#else
-#ifdef __linux__
-#pragma weak vsprintf = _IO_vsprintf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int vsprintf (char *, const char *, _IO_va_list)
+	      __attribute__ ((weak, "_IO_vsprintf"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsscanf.c	Wed Oct 22 18:17:55 1997
+++ ./iovsscanf.c	Thu Feb 25 12:12:06 1999
@@ -51,8 +51,9 @@ _IO_vsscanf (string, format, args)
 #ifdef weak_alias
 weak_alias (_IO_vsscanf, __vsscanf)
 weak_alias (_IO_vsscanf, vsscanf)
-#else
-#ifdef __linux__
-#pragma weak vsscanf = _IO_vsscanf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int __vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, "_IO_vsscanf"));
+int vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, "_IO_vsscanf"));
 #endif

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

HJ writes:

> Here is a libio patch for libc 5 using __attribute__ instead of pragma.
> It is totally untested since I no longer have libc 5 machine. Someone
> should check if it compiles and runs on libc 5.

I volunteer to test it, but I won't have time until this weekend.

Joe

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> HJ writes:
> 
> > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
> > It is totally untested since I no longer have libc 5 machine. Someone
> > should check if it compiles and runs on libc 5.
> 
> I volunteer to test it, but I won't have time until this weekend.
> 

I don't remember exactly how to trigger the bug. You may want to
try to use both fclose and iostream in C++ code linked with -static.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jonathan Larmour]

In article <m10G7KR-000390C.cygnus.egcs@ocean.lucon.org> you write:
>
>Here is a libio patch for libc 5 using __attribute__ instead of pragma.
>It is totally untested since I no longer have libc 5 machine. Someone
>should check if it compiles and runs on libc 5.
[snip]
>+void _cleanup () __attribute__ ((weak, "_IO_cleanup"));
[snip]

This isn't the correct syntax shurely? Don't you mean:

void _cleanup () __attribute__ ((weak, alias("_IO_cleanup")));

Assuming I'm right, if egcs doesn't complain about the format syntax, it
should.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"Women marry hoping their husbands will change, men||Home e-mail: jifl @ 
marry hoping their wives never do. Both are rare." ||     jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> This isn't the correct syntax shurely? Don't you mean:
> 
> void _cleanup () __attribute__ ((weak, alias("_IO_cleanup")));
> 
> Assuming I'm right, if egcs doesn't complain about the format syntax, it
> should.
> 

I told you it was not tested :-(.

Thanks. Here is the new patch.


H.J.
---
Thu Feb 25 12:17:52 1998  H.J. Lu  (hjl@gnu.org)

	* config/linuxlibc1.mt (MT_CFLAGS): Add -D_G_STDIO_USES_LIBIO
	-D_G_HAVE_WEAK_SYMBOL.

	* genops.c: Add the proper weak alias if _G_STDIO_USES_LIBIO
	and _G_HAVE_WEAK_SYMBOL are defined.
	* iofclose.c: Likewise.
	* iofeof.c: Likewise.
	* ioferror.c: Likewise.
	* iogetc.c: Likewise.
	* ioputc.c: Likewise.
	* iovsprintf.c: Likewise.
	* iovsscanf.c: Likewise.

--- ../../../import/egcs-1.1.x/egcs/libio/config/linuxlibc1.mt	Tue Feb 17 12:54:12 1998
+++ config/linuxlibc1.mt	Sat Feb  6 15:04:17 1999
@@ -23,4 +23,4 @@ USER_INCLUDES=PlotFile.h SFile.h builtin
 	streambuf.h strfile.h strstream.h libio.h
 
 # A bad kludge
-MT_CFLAGS=-D_G_HAVE_MMAP
+MT_CFLAGS=-D_G_HAVE_MMAP -D_G_STDIO_USES_LIBIO -D_G_HAVE_WEAK_SYMBOL
--- ../../../import/egcs-1.1.x/egcs/libio/./genops.c	Mon Jun  8 02:50:20 1998
+++ ./genops.c	Thu Feb 25 13:47:06 1999
@@ -937,6 +937,8 @@ __io_defs io_defs__;
 
 #ifdef weak_alias
 weak_alias (_IO_cleanup, _cleanup)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+void _cleanup () __attribute__ ((weak, alias ("_IO_cleanup")));
 #endif
 
 #ifdef text_set_element
--- ../../../import/egcs-1.1.x/egcs/libio/./iofclose.c	Thu Oct 16 08:30:23 1997
+++ ./iofclose.c	Thu Feb 25 13:47:17 1999
@@ -55,8 +55,6 @@ _IO_fclose (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_fclose, fclose)
-#else
-#ifdef __linux__
-#pragma weak fclose = _IO_fclose
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int fclose (_IO_FILE *) __attribute__ ((weak, alias("_IO_fclose")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iofeof.c	Sat Sep  6 00:42:56 1997
+++ ./iofeof.c	Thu Feb 25 13:47:26 1999
@@ -40,4 +40,6 @@ _IO_feof (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_feof, feof)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int feof (_IO_FILE *) __attribute__ ((weak, alias("_IO_feof")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioferror.c	Sat Sep  6 00:42:57 1997
+++ ./ioferror.c	Thu Feb 25 13:47:35 1999
@@ -40,4 +40,6 @@ _IO_ferror (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_ferror, ferror)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int ferror (_IO_FILE *) __attribute__ ((weak, alias("_IO_ferror")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iogetc.c	Sat Sep  6 00:43:15 1997
+++ ./iogetc.c	Thu Feb 25 13:47:42 1999
@@ -45,4 +45,6 @@ _IO_getc (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_getc, getc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int getc (_IO_FILE *) __attribute__ ((weak, alias("_IO_getc")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioputc.c	Sat Sep  6 00:43:25 1997
+++ ./ioputc.c	Thu Feb 25 13:47:52 1999
@@ -39,4 +39,6 @@ _IO_putc (c, fp)
 
 #ifdef weak_alias
 weak_alias (_IO_putc, putc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int putc (int, _IO_FILE *) __attribute__ ((weak, alias("_IO_putc")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsprintf.c	Thu Oct 16 08:30:23 1997
+++ ./iovsprintf.c	Thu Feb 25 13:48:03 1999
@@ -54,8 +54,7 @@ _IO_vsprintf (string, format, args)
 
 #ifdef weak_alias
 weak_alias (_IO_vsprintf, vsprintf)
-#else
-#ifdef __linux__
-#pragma weak vsprintf = _IO_vsprintf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int vsprintf (char *, const char *, _IO_va_list)
+	      __attribute__ ((weak, alias("_IO_vsprintf")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsscanf.c	Wed Oct 22 18:17:55 1997
+++ ./iovsscanf.c	Thu Feb 25 13:48:18 1999
@@ -51,8 +51,9 @@ _IO_vsscanf (string, format, args)
 #ifdef weak_alias
 weak_alias (_IO_vsscanf, __vsscanf)
 weak_alias (_IO_vsscanf, vsscanf)
-#else
-#ifdef __linux__
-#pragma weak vsscanf = _IO_vsscanf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int __vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, alias("_IO_vsscanf")));
+int vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, alias("_IO_vsscanf")));
 #endif

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902252055.MAA01705@atrus.synopsys.com >you write:
  > HJ writes:
  > 
  > > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
  > > It is totally untested since I no longer have libc 5 machine. Someone
  > > should check if it compiles and runs on libc 5.
  > 
  > I volunteer to test it, but I won't have time until this weekend.
Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on
one of my scratch disks to help test the libc5 issues.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> 
>   In message < 199902252055.MAA01705@atrus.synopsys.com >you write:
>   > HJ writes:
>   > 
>   > > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
>   > > It is totally untested since I no longer have libc 5 machine. Someone
>   > > should check if it compiles and runs on libc 5.
>   > 
>   > I volunteer to test it, but I won't have time until this weekend.
> Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on

Yes. But you have to compile a new binutils.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10GC2T-000390C@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < 199902252055.MAA01705@atrus.synopsys.com >you write:
  > >   > HJ writes:
  > >   > 
  > >   > > Here is a libio patch for libc 5 using __attribute__ instead of pra
  > gma.
  > >   > > It is totally untested since I no longer have libc 5 machine. Someo
  > ne
  > >   > > should check if it compiles and runs on libc 5.
  > >   > 
  > >   > I volunteer to test it, but I won't have time until this weekend.
  > > Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on
  > 
  > Yes. But you have to compile a new binutils.
That shouldn't be too bad.  And this is precisely what that scratch disk is
for :-)

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

> > Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on

HJ wrote:

> Yes. But you have to compile a new binutils.

I already have an RH 4.2 system with a new binutils compiled, which is
the one I plan to do the tests on.  Yes, it is libc5.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902260132.RAA01076@atrus.synopsys.com >you write:
  > I already have an RH 4.2 system with a new binutils compiled, which is
  > the one I plan to do the tests on.  Yes, it is libc5.
OK.  If you want to do it, that's fine by me.  Just trying to drive this
issue to completion.
jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

>   In message < 199902260132.RAA01076@atrus.synopsys.com >you write:
>   > I already have an RH 4.2 system with a new binutils compiled, which is
>   > the one I plan to do the tests on.  Yes, it is libc5.
> OK.  If you want to do it, that's fine by me.  Just trying to drive this
> issue to completion.

As I said to HJ, I won't have time to do these tests until this weekend,
so if you want to hack on it sooner, feel free.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

HJ wrote:
> > > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
> > > It is totally untested since I no longer have libc 5 machine. Someone
> > > should check if it compiles and runs on libc 5.

I replied:
> > I volunteer to test it, but I won't have time until this weekend.

HJ writes:
> I don't remember exactly how to trigger the bug. You may want to
> try to use both fclose and iostream in C++ code linked with -static.

I built egcs, using the CVS egcs_1_1_branch as of Friday about 10PM PST,
on my Red Hat 4.2 box (using 2.9.1.0.19a binutils for as and ld, rather
than the Red Hat version, so that exceptions will work correctly).  This
is without HJ's patch.  I used --enable-shared.

All the g++ tests pass (except of course for the expected failures).
I sent the report to egcs-testresults.

To try to duplicate the problem HJ has been talking about, I tried
the following test program:

------------------------------------------------
#include <stdio.h>
#include <fstream.h>
#include <string>

// write a file with stdio, read it with streams
int main(int argc, char** argv)
{
  if (argc != 2) {
    fprintf(stderr, "usage: %s file\n", argv[0]);
    return 1;
  }
  FILE * fd = fopen(argv[1], "w");
  fprintf (fd, "hello\n");
  fclose(fd);
  ifstream str(argv[1]);
  string s;
  str >> s;
  cout << s << endl;
}
------------------------------------------------

This program successfully runs without HJ's patch when built with
g++ -O2 -static iotest.cxx -o iotest

I tried other combinations, eg using the static libstdc++ and the
dynamic libc.  I couldn't make it fail.

Note that Red Hat 4.2 has libc 5.3.12 plus many Red Hat patches,
not libc 5.4.x.  Is it possible that the bug HJ is referring to
only shows up on libc 5.4.x systems?  (If so, do we have anyone
on egcs who has such a system who can try the test?).
Or is it possible that my test program isn't the correct test to
tweak the bug?

I don't think we should put the patch in unless we have a test
case that fails without the patch and passes with the patch.
If someone has a 5.4.x libc, could you try my test program
above?

Joe

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902271926.LAA06582@atrus.synopsys.com >you write:
  > HJ writes:
  > > I don't remember exactly how to trigger the bug. You may want to
  > > try to use both fclose and iostream in C++ code linked with -static.
  > 
  > I built egcs, using the CVS egcs_1_1_branch as of Friday about 10PM PST,
  > on my Red Hat 4.2 box (using 2.9.1.0.19a binutils for as and ld, rather
  > than the Red Hat version, so that exceptions will work correctly).  This
  > is without HJ's patch.  I used --enable-shared.
  > 
  > All the g++ tests pass (except of course for the expected failures).
  > I sent the report to egcs-testresults.
  > 
  > To try to duplicate the problem HJ has been talking about, I tried
  > the following test program:
I believe this message from the archives has enough of the original report
to build a testcase:  

http://www.cygnus.com/ml/egcs/1998-Jul/0986.html


jeff

ps.  I love online archives. :-)

pps.  My RH 4.2 box is really ready for testing yet.  Forgot how many little
pieces it needed to get going on my box.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902271926.LAA06582@atrus.synopsys.com >you write:
[ ... ]
  > Note that Red Hat 4.2 has libc 5.3.12 plus many Red Hat patches,
  > not libc 5.4.x.  Is it possible that the bug HJ is referring to
  > only shows up on libc 5.4.x systems?
Yes.  libc 5.3.xx doesn't have IO_putc in libc.a and thus does not trigger
the problem.

libc 5.4.xx does have IO_putc in libc.a:

[law@ralph /usr/lib] nm libc.a | grep IO_put
00000000 T _IO_puts
00000000 T _IO_putc


  > (If so, do we have anyone on egcs who has such a system who can try
  > the test?).
I've got RH4.2 up on my scratch disk and I just installed a libc5.4.xx
distribution, so I can cover testing.


Given the testcase referenced by my earlier message:

#include <iostream.h>
#include <streambuf.h>

istream x;
extern "C" int putc(), fgets();

main () {
  x.get();
  putc();
  fgets(); 
  x.gets(0, 0);
}

I've been able to reproduce the problem:

g++ -static foo.C
/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'
/usr/egcs/lib/libstdc++.a(ioputc.o):/puke/law/egcs-1.1/libio/ioputc.c:28: first defined here
/usr/bin/ld: Warning: size of symbol `_IO_putc' changed from 51 to 50 in putc.o
collect2: ld returned 1 exit status


It's very late.  I'm going to bed now.  I'll try to look at the patch tomorrow.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

>   > Note that Red Hat 4.2 has libc 5.3.12 plus many Red Hat patches,
>   > not libc 5.4.x.  Is it possible that the bug HJ is referring to
>   > only shows up on libc 5.4.x systems?
> Yes.  libc 5.3.xx doesn't have IO_putc in libc.a and thus does not trigger
> the problem.

I guess I shouldn't be surprised, as we worked hard to make egcs-1.0
work right on Red Hat 4.2 (since it was the most common Linux at that
time).

> I've got RH4.2 up on my scratch disk and I just installed a libc5.4.xx
> distribution, so I can cover testing.
> 
> 
> Given the testcase referenced by my earlier message:
> 
> #include <iostream.h>
> #include <streambuf.h>
> 
> istream x;
> extern "C" int putc(), fgets();
> 
> main () {
>   x.get();
>   putc();
>   fgets(); 
>   x.gets(0, 0);
> }
> 
> I've been able to reproduce the problem:

Could you add this as a testcase for the libio testsuite?

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> This isn't the correct syntax shurely? Don't you mean:
> 
> void _cleanup () __attribute__ ((weak, alias("_IO_cleanup")));
> 
> Assuming I'm right, if egcs doesn't complain about the format syntax, it
> should.
> 

I told you it was not tested :-(.

Thanks. Here is the new patch.


H.J.
---
Thu Feb 25 12:17:52 1998  H.J. Lu  (hjl@gnu.org)

	* config/linuxlibc1.mt (MT_CFLAGS): Add -D_G_STDIO_USES_LIBIO
	-D_G_HAVE_WEAK_SYMBOL.

	* genops.c: Add the proper weak alias if _G_STDIO_USES_LIBIO
	and _G_HAVE_WEAK_SYMBOL are defined.
	* iofclose.c: Likewise.
	* iofeof.c: Likewise.
	* ioferror.c: Likewise.
	* iogetc.c: Likewise.
	* ioputc.c: Likewise.
	* iovsprintf.c: Likewise.
	* iovsscanf.c: Likewise.

--- ../../../import/egcs-1.1.x/egcs/libio/config/linuxlibc1.mt	Tue Feb 17 12:54:12 1998
+++ config/linuxlibc1.mt	Sat Feb  6 15:04:17 1999
@@ -23,4 +23,4 @@ USER_INCLUDES=PlotFile.h SFile.h builtin
 	streambuf.h strfile.h strstream.h libio.h
 
 # A bad kludge
-MT_CFLAGS=-D_G_HAVE_MMAP
+MT_CFLAGS=-D_G_HAVE_MMAP -D_G_STDIO_USES_LIBIO -D_G_HAVE_WEAK_SYMBOL
--- ../../../import/egcs-1.1.x/egcs/libio/./genops.c	Mon Jun  8 02:50:20 1998
+++ ./genops.c	Thu Feb 25 13:47:06 1999
@@ -937,6 +937,8 @@ __io_defs io_defs__;
 
 #ifdef weak_alias
 weak_alias (_IO_cleanup, _cleanup)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+void _cleanup () __attribute__ ((weak, alias ("_IO_cleanup")));
 #endif
 
 #ifdef text_set_element
--- ../../../import/egcs-1.1.x/egcs/libio/./iofclose.c	Thu Oct 16 08:30:23 1997
+++ ./iofclose.c	Thu Feb 25 13:47:17 1999
@@ -55,8 +55,6 @@ _IO_fclose (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_fclose, fclose)
-#else
-#ifdef __linux__
-#pragma weak fclose = _IO_fclose
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int fclose (_IO_FILE *) __attribute__ ((weak, alias("_IO_fclose")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iofeof.c	Sat Sep  6 00:42:56 1997
+++ ./iofeof.c	Thu Feb 25 13:47:26 1999
@@ -40,4 +40,6 @@ _IO_feof (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_feof, feof)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int feof (_IO_FILE *) __attribute__ ((weak, alias("_IO_feof")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioferror.c	Sat Sep  6 00:42:57 1997
+++ ./ioferror.c	Thu Feb 25 13:47:35 1999
@@ -40,4 +40,6 @@ _IO_ferror (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_ferror, ferror)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int ferror (_IO_FILE *) __attribute__ ((weak, alias("_IO_ferror")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iogetc.c	Sat Sep  6 00:43:15 1997
+++ ./iogetc.c	Thu Feb 25 13:47:42 1999
@@ -45,4 +45,6 @@ _IO_getc (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_getc, getc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int getc (_IO_FILE *) __attribute__ ((weak, alias("_IO_getc")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioputc.c	Sat Sep  6 00:43:25 1997
+++ ./ioputc.c	Thu Feb 25 13:47:52 1999
@@ -39,4 +39,6 @@ _IO_putc (c, fp)
 
 #ifdef weak_alias
 weak_alias (_IO_putc, putc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int putc (int, _IO_FILE *) __attribute__ ((weak, alias("_IO_putc")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsprintf.c	Thu Oct 16 08:30:23 1997
+++ ./iovsprintf.c	Thu Feb 25 13:48:03 1999
@@ -54,8 +54,7 @@ _IO_vsprintf (string, format, args)
 
 #ifdef weak_alias
 weak_alias (_IO_vsprintf, vsprintf)
-#else
-#ifdef __linux__
-#pragma weak vsprintf = _IO_vsprintf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int vsprintf (char *, const char *, _IO_va_list)
+	      __attribute__ ((weak, alias("_IO_vsprintf")));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsscanf.c	Wed Oct 22 18:17:55 1997
+++ ./iovsscanf.c	Thu Feb 25 13:48:18 1999
@@ -51,8 +51,9 @@ _IO_vsscanf (string, format, args)
 #ifdef weak_alias
 weak_alias (_IO_vsscanf, __vsscanf)
 weak_alias (_IO_vsscanf, vsscanf)
-#else
-#ifdef __linux__
-#pragma weak vsscanf = _IO_vsscanf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int __vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, alias("_IO_vsscanf")));
+int vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, alias("_IO_vsscanf")));
 #endif

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10G46Y-000390C@ocean.lucon.org >you write:
  > Well, it seems a mess to me. We need TARGET_ATTRIBUTE_WEAK and
  > TARGET_ATTRIBUTE_WEAK_ALIAS for the target libraries
I don't this as a major problem.  What's the big deal?

  > They should be shared between gcc and libraries.
At some point, yes.  I don't think that needs to be a requirement today.

  > There is a include directory.
  > Should I put a "runtime.h" there and put the weak
  > definitions in it?
Let's not tackle this right now.  I'd like to get egcs-1.1.2 unstuck and out
the door.

Longer term, I can see having some file in libiberty which defines these
kinds of things for the host & target.

  > As for libio, Ulrich, are you still maintaining libio in egcs?
  > Can you take a look at my libio patch? I don't want to spend my
  > time on it without your input first.
HJ, please use the attribute like I have requested.  attributes are the GNU
standard, not pragmas.  Please use the attribute syntax.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

>   In message < 199902260132.RAA01076@atrus.synopsys.com >you write:
>   > I already have an RH 4.2 system with a new binutils compiled, which is
>   > the one I plan to do the tests on.  Yes, it is libc5.
> OK.  If you want to do it, that's fine by me.  Just trying to drive this
> issue to completion.

As I said to HJ, I won't have time to do these tests until this weekend,
so if you want to hack on it sooner, feel free.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10F2Hp-000390C@ocean.lucon.org >you write:
  > > 
  > > 
  > > > >   > 12. Fix libio for libc 5.
  > > > > Can't comment without a patch.
  > > > 
  > > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
  > > > 
  > > > You can see how old that patch is.
  > > 
  > > This one looks low-risk (it only makes some symbols weak).  It seems
  > > there's no risk of it destabilizing 1.1.2.
  > > 
  > > Of course it uses #pragma weak so if the rule now is to use attributes
  > > instead, I guess this patch must be adjusted.
  > > 
  > 
  > What is the attribute format for
  > 
  > #pragma weak old = new

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10G4vU-000390C@ocean.lucon.org >you write:
  > >   > Can you take a look at my libio patch? I don't want to spend my
  > >   > time on it without your input first.
  > > HJ, please use the attribute like I have requested.  attributes are the G
  > NU
  > > standard, not pragmas.  Please use the attribute syntax.
  > > 
  > 
  > egcs is not the only place where libio is used and libio doesn't use
  > attribute for weak. If Ulrich is still maintaining libio in egcs, I'd
  > like to hear what he has to say.
But libio is a GNU package and is compiled by GNU compilers.

Use the attribute syntax please.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902260132.RAA01076@atrus.synopsys.com >you write:
  > I already have an RH 4.2 system with a new binutils compiled, which is
  > the one I plan to do the tests on.  Yes, it is libc5.
OK.  If you want to do it, that's fine by me.  Just trying to drive this
issue to completion.
jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> > 
> > This one looks low-risk (it only makes some symbols weak).  It seems
> > there's no risk of it destabilizing 1.1.2.
> 
> Right now, we're chasing a problem regarding the interaction of weak and
> global symbols on some targets.  It's most often triggered by templates,
> but I think that's only becuase that's our number one producer of weak
> syms right now.
> 

My libio patch will only affect systems which define both
_G_STDIO_USES_LIBIO and _G_HAVE_WEAK_SYMBOL. I blieve only
Linux does that.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

HJ wrote:
> > > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
> > > It is totally untested since I no longer have libc 5 machine. Someone
> > > should check if it compiles and runs on libc 5.

I replied:
> > I volunteer to test it, but I won't have time until this weekend.

HJ writes:
> I don't remember exactly how to trigger the bug. You may want to
> try to use both fclose and iostream in C++ code linked with -static.

I built egcs, using the CVS egcs_1_1_branch as of Friday about 10PM PST,
on my Red Hat 4.2 box (using 2.9.1.0.19a binutils for as and ld, rather
than the Red Hat version, so that exceptions will work correctly).  This
is without HJ's patch.  I used --enable-shared.

All the g++ tests pass (except of course for the expected failures).
I sent the report to egcs-testresults.

To try to duplicate the problem HJ has been talking about, I tried
the following test program:

------------------------------------------------
#include <stdio.h>
#include <fstream.h>
#include <string>

// write a file with stdio, read it with streams
int main(int argc, char** argv)
{
  if (argc != 2) {
    fprintf(stderr, "usage: %s file\n", argv[0]);
    return 1;
  }
  FILE * fd = fopen(argv[1], "w");
  fprintf (fd, "hello\n");
  fclose(fd);
  ifstream str(argv[1]);
  string s;
  str >> s;
  cout << s << endl;
}
------------------------------------------------

This program successfully runs without HJ's patch when built with
g++ -O2 -static iotest.cxx -o iotest

I tried other combinations, eg using the static libstdc++ and the
dynamic libc.  I couldn't make it fail.

Note that Red Hat 4.2 has libc 5.3.12 plus many Red Hat patches,
not libc 5.4.x.  Is it possible that the bug HJ is referring to
only shows up on libc 5.4.x systems?  (If so, do we have anyone
on egcs who has such a system who can try the test?).
Or is it possible that my test program isn't the correct test to
tweak the bug?

I don't think we should put the patch in unless we have a test
case that fails without the patch and passes with the patch.
If someone has a 5.4.x libc, could you try my test program
above?

Joe

Re: An egcs 1.1.2 patch for Linux/Alpha

[Jeffrey A Law]

  In message < 199902231750.JAA04017@atrus.synopsys.com >you write:
  > In practice, the submitter may not be able to know this in all cases, but
  > may still have a strong belief that a patch is needed to fix a problem
  > that is found at the last minute.
Certainly.  But I think the submitter needs to at least check on this kind
of stuff.  A simple walk through the ChangeLog or the CVS repo looking for
additional changs to the same file and/or function is not too much to task
IMHO.

I'll note this is precisely what other contributors have done when submitting
old patches from the mainline sources to the branch, or what I do when picking
up an old patch from the mainline tree.  It's not terribly difficult to catch
obvious dependencies this way.  It's by no means foolproof, but it's better
than submitting a patch without any checking at all!

Why can't HJ do this like other folks?  Only caring about Linux is not an
excuse for not doing this kind of research for a patch.




  > In this case, HJ knew he put in a fix to a problem, and knew it had been
  > checked in a while ago (so it is reasonable for him to think it was a safe
  > and tested patch), but there wasn't an easy way to "cross-reference"
  > the fact that it needed later fixes.  I don't know if there's a simple
  > way to keep better track of these things or not.
There is no good cross-referencing for this kind of stuff (you can bet we've
been fighting this issue internally at Cygnus for a while).  However, ChangeLog
scanning will usually expose obvious dependencies or at least give a list of
changes someone more qualified needs to look at when evaluating a release
branch patch.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902271926.LAA06582@atrus.synopsys.com >you write:
[ ... ]
  > Note that Red Hat 4.2 has libc 5.3.12 plus many Red Hat patches,
  > not libc 5.4.x.  Is it possible that the bug HJ is referring to
  > only shows up on libc 5.4.x systems?
Yes.  libc 5.3.xx doesn't have IO_putc in libc.a and thus does not trigger
the problem.

libc 5.4.xx does have IO_putc in libc.a:

[law@ralph /usr/lib] nm libc.a | grep IO_put
00000000 T _IO_puts
00000000 T _IO_putc


  > (If so, do we have anyone on egcs who has such a system who can try
  > the test?).
I've got RH4.2 up on my scratch disk and I just installed a libc5.4.xx
distribution, so I can cover testing.


Given the testcase referenced by my earlier message:

#include <iostream.h>
#include <streambuf.h>

istream x;
extern "C" int putc(), fgets();

main () {
  x.get();
  putc();
  fgets(); 
  x.gets(0, 0);
}

I've been able to reproduce the problem:

g++ -static foo.C
/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'
/usr/egcs/lib/libstdc++.a(ioputc.o):/puke/law/egcs-1.1/libio/ioputc.c:28: first defined here
/usr/bin/ld: Warning: size of symbol `_IO_putc' changed from 51 to 50 in putc.o
collect2: ld returned 1 exit status


It's very late.  I'm going to bed now.  I'll try to look at the patch tomorrow.

jeff

A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
>   > 12. Fix libio for libc 5.
> Can't comment without a patch.

http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html

You can see how old that patch is.


H.J.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Ulrich Drepper]

hjl@lucon.org (H.J. Lu) writes:

> As for libio, Ulrich, are you still maintaining libio in egcs?
> Can you take a look at my libio patch? I don't want to spend my
> time on it without your input first.

I can take a look but I don't know whether I have the time today.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: An egcs 1.1.2 patch for Linux/Alpha

[Joe Buck]

Jeff writes:

> When you submit patches to a release branch, you need try harder to make
> sure they will not break other ports.  It is *critical* that a minor release
> not take a step backwards like that.

In practice, the submitter may not be able to know this in all cases, but
may still have a strong belief that a patch is needed to fix a problem
that is found at the last minute.

The risk is largest for patches that are proposed for the release branch
but have never been in the mainline.  But the case you're talking about here
is interesting because HJ's patch had been in the mainline, together with
Richard's patches to fix HJ's patches.  But HJ didn't seem aware of that.
We don't really have a system to manage this kind of dependency.

In this case, HJ knew he put in a fix to a problem, and knew it had been
checked in a while ago (so it is reasonable for him to think it was a safe
and tested patch), but there wasn't an easy way to "cross-reference"
the fact that it needed later fixes.  I don't know if there's a simple
way to keep better track of these things or not.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902271926.LAA06582@atrus.synopsys.com >you write:
  > HJ writes:
  > > I don't remember exactly how to trigger the bug. You may want to
  > > try to use both fclose and iostream in C++ code linked with -static.
  > 
  > I built egcs, using the CVS egcs_1_1_branch as of Friday about 10PM PST,
  > on my Red Hat 4.2 box (using 2.9.1.0.19a binutils for as and ld, rather
  > than the Red Hat version, so that exceptions will work correctly).  This
  > is without HJ's patch.  I used --enable-shared.
  > 
  > All the g++ tests pass (except of course for the expected failures).
  > I sent the report to egcs-testresults.
  > 
  > To try to duplicate the problem HJ has been talking about, I tried
  > the following test program:
I believe this message from the archives has enough of the original report
to build a testcase:  

http://www.cygnus.com/ml/egcs/1998-Jul/0986.html


jeff

ps.  I love online archives. :-)

pps.  My RH 4.2 box is really ready for testing yet.  Forgot how many little
pieces it needed to get going on my box.

Re: An egcs 1.1.2 patch for Linux/Alpha

[Jeffrey A Law]

  In message < m10F1l6-000390C@ocean.lucon.org >you write:
  > >   > 1. Better support for Linux/Alpha. It is just one line change:
  > >   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
  > >   >        * ginclude/va-alpha.h (va_list): Use a typedef, not a define.
  > > Submit it.
  > > 
  > 
  > I was told it might need another patch from Richard to get it to
  > work on OSF/Alpha. But I have no way to tell.
  > 
  > 
  > H.J.
  > ---
  > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
  > 
  > 	* ginclude/va-alpha.h (va_list): Use a typedef, not a define.
I've applied this along with Richard's patches.

Note carefully that had other folks not pointed out the need for Richard's
patch we could have totally busted the alpha-dec-osf* port.

When you submit patches to a release branch, you need try harder to make
sure they will not break other ports.  It is *critical* that a minor release
not take a step backwards like that.


Thanks,
jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

HJ writes:

> Here is a libio patch for libc 5 using __attribute__ instead of pragma.
> It is totally untested since I no longer have libc 5 machine. Someone
> should check if it compiles and runs on libc 5.

I volunteer to test it, but I won't have time until this weekend.

Joe

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> 
>   In message < 199902252055.MAA01705@atrus.synopsys.com >you write:
>   > HJ writes:
>   > 
>   > > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
>   > > It is totally untested since I no longer have libc 5 machine. Someone
>   > > should check if it compiles and runs on libc 5.
>   > 
>   > I volunteer to test it, but I won't have time until this weekend.
> Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on

Yes. But you have to compile a new binutils.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux cross-compile patch

[Jeffrey A Law]

  In message < m10F1nl-000390C@ocean.lucon.org >you write:
  > >   > 4. Better support for cross-compile. I fixed a bug you may only see
  > >   > when you do cross-compile from one Linux to another Linux. It is in
  > >   > the mainline now. But I need it for egcs 1.1.2.
  > > Again, without a patch I can't comment.
  > 
  > http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00280.html
Note this is the first time as far as I know that you've mentioned this
patch was important for egcs-1.1.2.

It would avoid a lot of headaches in the future if you would indicate
that a patch is important for a minor release and way.

In many ways, this is no different than explaining the technical details
behind a patch -- when you leave out critical information I have to make
decisions based on my own best judgement.  Sometimes that judgement is wrong,
or does not parallel your own ideas.  Far better for you to be explicit about
this stuff and avoid the problems and wasted time in the first place.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Robert Lipe]

> > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> 
> This one looks low-risk (it only makes some symbols weak).  It seems
> there's no risk of it destabilizing 1.1.2.

Right now, we're chasing a problem regarding the interaction of weak and
global symbols on some targets.  It's most often triggered by templates,
but I think that's only becuase that's our number one producer of weak
syms right now.

RJL

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jonathan Larmour]

In article <m10G7KR-000390C.cygnus.egcs@ocean.lucon.org> you write:
>
>Here is a libio patch for libc 5 using __attribute__ instead of pragma.
>It is totally untested since I no longer have libc 5 machine. Someone
>should check if it compiles and runs on libc 5.
[snip]
>+void _cleanup () __attribute__ ((weak, "_IO_cleanup"));
[snip]

This isn't the correct syntax shurely? Don't you mean:

void _cleanup () __attribute__ ((weak, alias("_IO_cleanup")));

Assuming I'm right, if egcs doesn't complain about the format syntax, it
should.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"Women marry hoping their husbands will change, men||Home e-mail: jifl @ 
marry hoping their wives never do. Both are rare." ||     jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

A Linux cross-compile patch

[H.J. Lu]

>   > 4. Better support for cross-compile. I fixed a bug you may only see
>   > when you do cross-compile from one Linux to another Linux. It is in
>   > the mainline now. But I need it for egcs 1.1.2.
> Again, without a patch I can't comment.

http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00280.html


H.J.

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

>   > Note that Red Hat 4.2 has libc 5.3.12 plus many Red Hat patches,
>   > not libc 5.4.x.  Is it possible that the bug HJ is referring to
>   > only shows up on libc 5.4.x systems?
> Yes.  libc 5.3.xx doesn't have IO_putc in libc.a and thus does not trigger
> the problem.

I guess I shouldn't be surprised, as we worked hard to make egcs-1.0
work right on Red Hat 4.2 (since it was the most common Linux at that
time).

> I've got RH4.2 up on my scratch disk and I just installed a libc5.4.xx
> distribution, so I can cover testing.
> 
> 
> Given the testcase referenced by my earlier message:
> 
> #include <iostream.h>
> #include <streambuf.h>
> 
> istream x;
> extern "C" int putc(), fgets();
> 
> main () {
>   x.get();
>   putc();
>   fgets(); 
>   x.gets(0, 0);
> }
> 
> I've been able to reproduce the problem:

Could you add this as a testcase for the libio testsuite?

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

> >   > 12. Fix libio for libc 5.
> > Can't comment without a patch.
> 
> http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> 
> You can see how old that patch is.

This one looks low-risk (it only makes some symbols weak).  It seems
there's no risk of it destabilizing 1.1.2.

Of course it uses #pragma weak so if the rule now is to use attributes
instead, I guess this patch must be adjusted.

Re: An egcs 1.1.2 patch for Linux/Alpha

[Richard Henderson]

On Mon, Feb 22, 1999 at 12:15:16PM -0800, H.J. Lu wrote:
> I was told it might need another patch from Richard to get it to
> work on OSF/Alpha. But I have no way to tell.

Thu Sep  3 00:23:21 1998  Richard Henderson  <rth@cygnus.com>

        * ginclude/va-alpha.h: Protect entire second portion of the
        file against double inclusion.

Mon Aug 31 13:57:55 1998  Richard Henderson  <rth@cygnus.com>

        * alpha/va_list.h: New file.
        * alpha/x-alpha (EXTRA_HEADERS): New.  Add va_list.h.


r~

Re: An egcs 1.1.2 patch for Linux/Alpha

[H.J. Lu]

> 
> 
> 
>   In message < m10F1l6-000390C@ocean.lucon.org >you write:
>   > >   > 1. Better support for Linux/Alpha. It is just one line change:
>   > >   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
>   > >   >        * ginclude/va-alpha.h (va_list): Use a typedef, not a define.
>   > > Submit it.
>   > > 
>   > 
>   > I was told it might need another patch from Richard to get it to
>   > work on OSF/Alpha. But I have no way to tell.
>   > 
>   > 
>   > H.J.
>   > ---
>   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
>   > 
>   > 	* ginclude/va-alpha.h (va_list): Use a typedef, not a define.
> I've applied this along with Richard's patches.
> 

Thanks.

> Note carefully that had other folks not pointed out the need for Richard's
> patch we could have totally busted the alpha-dec-osf* port.
> 
> When you submit patches to a release branch, you need try harder to make
> sure they will not break other ports.  It is *critical* that a minor release
> not take a step backwards like that.
> 

I don't have any OSF/Alpha machines. I need help from others.


-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Joe Buck]

> > Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on

HJ wrote:

> Yes. But you have to compile a new binutils.

I already have an RH 4.2 system with a new binutils compiled, which is
the one I plan to do the tests on.  Yes, it is libc5.

An egcs 1.1.2 patch for Linux/Alpha

[H.J. Lu]

>   > 1. Better support for Linux/Alpha. It is just one line change:
>   > Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>
>   >        * ginclude/va-alpha.h (va_list): Use a typedef, not a define.
> Submit it.
> 

I was told it might need another patch from Richard to get it to
work on OSF/Alpha. But I have no way to tell.


H.J.
---
Sat Aug  1 17:59:30 1998  Richard Henderson  <rth@cygnus.com>

	* ginclude/va-alpha.h (va_list): Use a typedef, not a define.

--- /home/work/misc/gnu/import/egcs/gcc/ginclude/va-alpha.h	Mon Aug 11 08:58:05 1997
+++ ginclude/va-alpha.h	Fri Jan 15 10:23:57 1999
@@ -28,8 +28,8 @@
 /* If this is for internal libc use, don't define anything but
    __gnuc_va_list.  */
 #if defined (_STDARG_H) || defined (_VARARGS_H)
+typedef __gnuc_va_list va_list;
 
-#define va_list __gnuc_va_list
 #define _VA_LIST
 #define _VA_LIST_
 

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10GC2T-000390C@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < 199902252055.MAA01705@atrus.synopsys.com >you write:
  > >   > HJ writes:
  > >   > 
  > >   > > Here is a libio patch for libc 5 using __attribute__ instead of pra
  > gma.
  > >   > > It is totally untested since I no longer have libc 5 machine. Someo
  > ne
  > >   > > should check if it compiles and runs on libc 5.
  > >   > 
  > >   > I volunteer to test it, but I won't have time until this weekend.
  > > Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on
  > 
  > Yes. But you have to compile a new binutils.
That shouldn't be too bad.  And this is precisely what that scratch disk is
for :-)

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < m10F2Hp-000390C@ocean.lucon.org >you write:
  > Should we have a central location for it? If we do, I can also fix libobjc.
  > We should move those weak stuffs out of gthr-*. Many other places need the 
  > same information also.
BTW, I'm not sure if we have a common location where we can add a weak-alias
attribute definition for use by target libraries outside of the gcc
subdirectory.


jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

>   > Can you take a look at my libio patch? I don't want to spend my
>   > time on it without your input first.
> HJ, please use the attribute like I have requested.  attributes are the GNU
> standard, not pragmas.  Please use the attribute syntax.
> 

egcs is not the only place where libio is used and libio doesn't use
attribute for weak. If Ulrich is still maintaining libio in egcs, I'd
like to hear what he has to say.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

>   > > 
>   > > > >   > 12. Fix libio for libc 5.
>   > > > > Can't comment without a patch.
>   > > > 
>   > > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
>   > > > 
>   > > > You can see how old that patch is.
>   > > 
>   > > This one looks low-risk (it only makes some symbols weak).  It seems
>   > > there's no risk of it destabilizing 1.1.2.
>   > > 
>   > > Of course it uses #pragma weak so if the rule now is to use attributes
>   > > instead, I guess this patch must be adjusted.
>   > > 
>   > 
>   > What is the attribute format for
>   > 
>   > #pragma weak old = new
> >From the manual:
> @cindex @code{alias} attribute
> The @code{alias} attribute causes the declaration to be emitted as an
> alias for another symbol, which must be specified.  For instance,
> 
> @smallexample
> void __f () @{ /* do something */; @}
> void f () __attribute__ ((weak, alias ("__f")));
> @end smallexample
> 
> declares @samp{f} to be a weak alias for @samp{__f}.  In C++, the
> mangled name for the target must be used.
> 
> Sounds like we need TARGET_ATTRIBUTE_WEAK_ALIAS
> 

Well, it seems a mess to me. We need TARGET_ATTRIBUTE_WEAK and
TARGET_ATTRIBUTE_WEAK_ALIAS for the target libraries. They
should be shared between gcc and libraries. There is a include
directory. Should I put a "runtime.h" there and put the weak
definitions in it? Also, somehow we need to make the target
runtime information available to libraries. Right now only gcc
knows it. Maybe it can be done for egcs 1.2.

As for libio, Ulrich, are you still maintaining libio in egcs?
Can you take a look at my libio patch? I don't want to spend my
time on it without your input first.

Thanks.



-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> 
> > >   > 12. Fix libio for libc 5.
> > > Can't comment without a patch.
> > 
> > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
> > 
> > You can see how old that patch is.
> 
> This one looks low-risk (it only makes some symbols weak).  It seems
> there's no risk of it destabilizing 1.1.2.
> 
> Of course it uses #pragma weak so if the rule now is to use attributes
> instead, I guess this patch must be adjusted.
> 

What is the attribute format for

#pragma weak old = new

Should we have a central location for it? If we do, I can also fix libobjc.
We should move those weak stuffs out of gthr-*. Many other places need the same
information also.


-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> 
> HJ writes:
> 
> > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
> > It is totally untested since I no longer have libc 5 machine. Someone
> > should check if it compiles and runs on libc 5.
> 
> I volunteer to test it, but I won't have time until this weekend.
> 

I don't remember exactly how to trigger the bug. You may want to
try to use both fclose and iostream in C++ code linked with -static.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

>   > > > >   > 12. Fix libio for libc 5.
>   > > > > Can't comment without a patch.
>   > > > 
>   > > > http://www.cygnus.com/ml/egcs-patches/1998-Jul/0578.html
>   > > > 
>   > > > You can see how old that patch is.
>   > > 
>   > > This one looks low-risk (it only makes some symbols weak).  It seems
>   > > there's no risk of it destabilizing 1.1.2.
>   > > 
>   > > Of course it uses #pragma weak so if the rule now is to use attributes
>   > > instead, I guess this patch must be adjusted.
>   > > 
>   > 

Here is a libio patch for libc 5 using __attribute__ instead of pragma.
It is totally untested since I no longer have libc 5 machine. Someone
should check if it compiles and runs on libc 5.

BTW, pragma is in the current libio. I have to take some of them out
for __attribute__.

Thanks.


----
Thu Feb 25 12:17:52 1998  H.J. Lu  (hjl@gnu.org)

	* config/linuxlibc1.mt (MT_CFLAGS): Add -D_G_STDIO_USES_LIBIO
	-D_G_HAVE_WEAK_SYMBOL.

	* genops.c: Add the proper weak alias if _G_STDIO_USES_LIBIO
	and _G_HAVE_WEAK_SYMBOL are defined.
	* iofclose.c: Likewise.
	* iofeof.c: Likewise.
	* ioferror.c: Likewise.
	* iogetc.c: Likewise.
	* ioputc.c: Likewise.
	* iovsprintf.c: Likewise.
	* iovsscanf.c: Likewise.

--- ../../../import/egcs-1.1.x/egcs/libio/config/linuxlibc1.mt	Tue Feb 17 12:54:12 1998
+++ config/linuxlibc1.mt	Sat Feb  6 15:04:17 1999
@@ -23,4 +23,4 @@ USER_INCLUDES=PlotFile.h SFile.h builtin
 	streambuf.h strfile.h strstream.h libio.h
 
 # A bad kludge
-MT_CFLAGS=-D_G_HAVE_MMAP
+MT_CFLAGS=-D_G_HAVE_MMAP -D_G_STDIO_USES_LIBIO -D_G_HAVE_WEAK_SYMBOL
--- ../../../import/egcs-1.1.x/egcs/libio/./genops.c	Mon Jun  8 02:50:20 1998
+++ ./genops.c	Thu Feb 25 12:05:49 1999
@@ -937,6 +937,8 @@ __io_defs io_defs__;
 
 #ifdef weak_alias
 weak_alias (_IO_cleanup, _cleanup)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+void _cleanup () __attribute__ ((weak, "_IO_cleanup"));
 #endif
 
 #ifdef text_set_element
--- ../../../import/egcs-1.1.x/egcs/libio/./iofclose.c	Thu Oct 16 08:30:23 1997
+++ ./iofclose.c	Thu Feb 25 12:07:15 1999
@@ -55,8 +55,6 @@ _IO_fclose (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_fclose, fclose)
-#else
-#ifdef __linux__
-#pragma weak fclose = _IO_fclose
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int fclose (_IO_FILE *) __attribute__ ((weak, "_IO_fclose"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iofeof.c	Sat Sep  6 00:42:56 1997
+++ ./iofeof.c	Thu Feb 25 12:07:43 1999
@@ -40,4 +40,6 @@ _IO_feof (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_feof, feof)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int feof (_IO_FILE *) __attribute__ ((weak, "_IO_feof"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioferror.c	Sat Sep  6 00:42:57 1997
+++ ./ioferror.c	Thu Feb 25 12:08:10 1999
@@ -40,4 +40,6 @@ _IO_ferror (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_ferror, ferror)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int ferror (_IO_FILE *) __attribute__ ((weak, "_IO_ferror"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iogetc.c	Sat Sep  6 00:43:15 1997
+++ ./iogetc.c	Thu Feb 25 12:08:53 1999
@@ -45,4 +45,6 @@ _IO_getc (fp)
 
 #ifdef weak_alias
 weak_alias (_IO_getc, getc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int getc (_IO_FILE *) __attribute__ ((weak, "_IO_getc"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./ioputc.c	Sat Sep  6 00:43:25 1997
+++ ./ioputc.c	Thu Feb 25 12:09:56 1999
@@ -39,4 +39,6 @@ _IO_putc (c, fp)
 
 #ifdef weak_alias
 weak_alias (_IO_putc, putc)
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int putc (int, _IO_FILE *) __attribute__ ((weak, "_IO_putc"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsprintf.c	Thu Oct 16 08:30:23 1997
+++ ./iovsprintf.c	Thu Feb 25 12:10:47 1999
@@ -54,8 +54,7 @@ _IO_vsprintf (string, format, args)
 
 #ifdef weak_alias
 weak_alias (_IO_vsprintf, vsprintf)
-#else
-#ifdef __linux__
-#pragma weak vsprintf = _IO_vsprintf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int vsprintf (char *, const char *, _IO_va_list)
+	      __attribute__ ((weak, "_IO_vsprintf"));
 #endif
--- ../../../import/egcs-1.1.x/egcs/libio/./iovsscanf.c	Wed Oct 22 18:17:55 1997
+++ ./iovsscanf.c	Thu Feb 25 12:12:06 1999
@@ -51,8 +51,9 @@ _IO_vsscanf (string, format, args)
 #ifdef weak_alias
 weak_alias (_IO_vsscanf, __vsscanf)
 weak_alias (_IO_vsscanf, vsscanf)
-#else
-#ifdef __linux__
-#pragma weak vsscanf = _IO_vsscanf
-#endif
+#elif defined(_G_STDIO_USES_LIBIO) && defined(_G_HAVE_WEAK_SYMBOL)
+int __vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, "_IO_vsscanf"));
+int vsscanf (const char *, const char *, _IO_va_list)
+	    __attribute__ ((weak, "_IO_vsscanf"));
 #endif

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message < 199902252055.MAA01705@atrus.synopsys.com >you write:
  > HJ writes:
  > 
  > > Here is a libio patch for libc 5 using __attribute__ instead of pragma.
  > > It is totally untested since I no longer have libc 5 machine. Someone
  > > should check if it compiles and runs on libc 5.
  > 
  > I volunteer to test it, but I won't have time until this weekend.
Does anyone remember if RH 4.2 was a libc5 system?  I can load it up on
one of my scratch disks to help test the libc5 issues.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message <199902282133.NAA24574@atrus.synopsys.com>you write:
  > I guess I shouldn't be surprised, as we worked hard to make egcs-1.0
  > work right on Red Hat 4.2 (since it was the most common Linux at that
  > time).
Yup.

  > Could you add this as a testcase for the libio testsuite?
That's the plan.

It actually looks like libio has been hacked before to address this exact
issue.  Every function HJ's patch makes weak the code already tries to make
weak, but is failing.

Basically it tests #ifdef weak_alias which isn't defined anywhere in libio
or in include files included by files in libio.

I found its definition in gnu-stabs.h on my RH4.2 box.  Ugh.

We could easily get the same net result by defining weak_alias in a common
header file in libio.  However, I didn't see one that was common, but
internal to libio (we don't want to pollute the namespace).

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message <199902282133.NAA24574@atrus.synopsys.com>you write:
  > > Given the testcase referenced by my earlier message:
  > > 
  > > #include <iostream.h>
  > > #include <streambuf.h>
  > > 
  > > istream x;
  > > extern "C" int putc(), fgets();
  > > 
  > > main () {
  > >   x.get();
  > >   putc();
  > >   fgets(); 
  > >   x.gets(0, 0);
  > > }
  > > 
  > > I've been able to reproduce the problem:
  > 
  > Could you add this as a testcase for the libio testsuite?
It turns out this doesn't fit all that well into the libio testsuite, but
I believe I can make it fit into the g++ testsuite.  Better than nothing
I suppose.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message <m10G8fy-000390C@ocean.lucon.org>you write:
  > Thanks. Here is the new patch.
  > 
  > 
  > H.J.
  > ---
  > Thu Feb 25 12:17:52 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* config/linuxlibc1.mt (MT_CFLAGS): Add -D_G_STDIO_USES_LIBIO
  > 	-D_G_HAVE_WEAK_SYMBOL.
  > 
  > 	* genops.c: Add the proper weak alias if _G_STDIO_USES_LIBIO
  > 	and _G_HAVE_WEAK_SYMBOL are defined.
  > 	* iofclose.c: Likewise.
  > 	* iofeof.c: Likewise.
  > 	* ioferror.c: Likewise.
  > 	* iogetc.c: Likewise.
  > 	* ioputc.c: Likewise.
  > 	* iovsprintf.c: Likewise.
  > 	* iovsscanf.c: Likewise.
Thanks.  I have installed this into the mainline and the release branch.  We
still need to decide how to resolve the problems with the functions that
are defined by libc.a(genops.o) which are not defined by libstdc++.a(genops.o).

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> Thanks.  I have installed this into the mainline and the release branch.  We

Thanks.

> still need to decide how to resolve the problems with the functions that
> are defined by libc.a(genops.o) which are not defined by libstdc++.a(genops.o).
> 

I have told you in a different email that it is not a problem.
As I said before, libio is a tricky one. You have to know
what you are doing when you work on it.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

> Thanks.  I have installed this into the mainline and the release branch.  We

Thanks.

> still need to decide how to resolve the problems with the functions that
> are defined by libc.a(genops.o) which are not defined by libstdc++.a(genops.o).
> 

I have told you in a different email that it is not a problem.
As I said before, libio is a tricky one. You have to know
what you are doing when you work on it.

-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message <199902282133.NAA24574@atrus.synopsys.com>you write:
  > > Given the testcase referenced by my earlier message:
  > > 
  > > #include <iostream.h>
  > > #include <streambuf.h>
  > > 
  > > istream x;
  > > extern "C" int putc(), fgets();
  > > 
  > > main () {
  > >   x.get();
  > >   putc();
  > >   fgets(); 
  > >   x.gets(0, 0);
  > > }
  > > 
  > > I've been able to reproduce the problem:
  > 
  > Could you add this as a testcase for the libio testsuite?
It turns out this doesn't fit all that well into the libio testsuite, but
I believe I can make it fit into the g++ testsuite.  Better than nothing
I suppose.

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message <199902282133.NAA24574@atrus.synopsys.com>you write:
  > I guess I shouldn't be surprised, as we worked hard to make egcs-1.0
  > work right on Red Hat 4.2 (since it was the most common Linux at that
  > time).
Yup.

  > Could you add this as a testcase for the libio testsuite?
That's the plan.

It actually looks like libio has been hacked before to address this exact
issue.  Every function HJ's patch makes weak the code already tries to make
weak, but is failing.

Basically it tests #ifdef weak_alias which isn't defined anywhere in libio
or in include files included by files in libio.

I found its definition in gnu-stabs.h on my RH4.2 box.  Ugh.

We could easily get the same net result by defining weak_alias in a common
header file in libio.  However, I didn't see one that was common, but
internal to libio (we don't want to pollute the namespace).

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[Jeffrey A Law]

  In message <m10G8fy-000390C@ocean.lucon.org>you write:
  > Thanks. Here is the new patch.
  > 
  > 
  > H.J.
  > ---
  > Thu Feb 25 12:17:52 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* config/linuxlibc1.mt (MT_CFLAGS): Add -D_G_STDIO_USES_LIBIO
  > 	-D_G_HAVE_WEAK_SYMBOL.
  > 
  > 	* genops.c: Add the proper weak alias if _G_STDIO_USES_LIBIO
  > 	and _G_HAVE_WEAK_SYMBOL are defined.
  > 	* iofclose.c: Likewise.
  > 	* iofeof.c: Likewise.
  > 	* ioferror.c: Likewise.
  > 	* iogetc.c: Likewise.
  > 	* ioputc.c: Likewise.
  > 	* iovsprintf.c: Likewise.
  > 	* iovsscanf.c: Likewise.
Thanks.  I have installed this into the mainline and the release branch.  We
still need to decide how to resolve the problems with the functions that
are defined by libc.a(genops.o) which are not defined by libstdc++.a(genops.o).

jeff

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

libio is a complicated code and it is used in libc5/glibc2/egcs. If you
haven't worked on it before, I would strongly recommend you do

1. Use my patch with few changes. Or
2. Talk to Ulrich first before you make any modifications of your own
and let me go over your changes to see if there are any obvious holes.


-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[H.J. Lu]

libio is a complicated code and it is used in libc5/glibc2/egcs. If you
haven't worked on it before, I would strongly recommend you do

1. Use my patch with few changes. Or
2. Talk to Ulrich first before you make any modifications of your own
and let me go over your changes to see if there are any obvious holes.


-- 
H.J. Lu (hjl@gnu.org)

Re: A Linux/libc 5 patch for egcs 1.1.2

[Josh Stern]

Since people are looking at iostream issues...can anyone explain
the decision to use the included rather than the commented out
versions of tellp() and tellg() in iostream?  It looks like that
makes it impossible for tellp() and tellg() to work correctly in
a derived class that uses a different streambuf.  Or am I missing
something?

- Josh

Re: A Linux/libc 5 patch for egcs 1.1.2

[Per Bothner]

> Since people are looking at iostream issues...can anyone explain
> the decision to use the included rather than the commented out
> versions of tellp() and tellg() in iostream?

Well, they're the same (look at the definition of pubseekoff),
and the comment-out-version is more efficient, I guess (though
if inlining is in effect, it shouldn't matter).  More - I don't
remember.

> It looks like that
> makes it impossible for tellp() and tellg() to work correctly in
> a derived class that uses a different streambuf.

What makes you think that?  _IO_seekoff invokes the macro
_IO_SEEKOFF, which calls the __seekoff jump table entry.
This is the same function as the seekoff vtable entry.

Read the comments in libioP.h.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: A Linux/libc 5 patch for egcs 1.1.2

[Per Bothner]

> Since people are looking at iostream issues...can anyone explain
> the decision to use the included rather than the commented out
> versions of tellp() and tellg() in iostream?

Well, they're the same (look at the definition of pubseekoff),
and the comment-out-version is more efficient, I guess (though
if inlining is in effect, it shouldn't matter).  More - I don't
remember.

> It looks like that
> makes it impossible for tellp() and tellg() to work correctly in
> a derived class that uses a different streambuf.

What makes you think that?  _IO_seekoff invokes the macro
_IO_SEEKOFF, which calls the __seekoff jump table entry.
This is the same function as the seekoff vtable entry.

Read the comments in libioP.h.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: A Linux/libc 5 patch for egcs 1.1.2

[Josh Stern]

Since people are looking at iostream issues...can anyone explain
the decision to use the included rather than the commented out
versions of tellp() and tellg() in iostream?  It looks like that
makes it impossible for tellp() and tellg() to work correctly in
a derived class that uses a different streambuf.  Or am I missing
something?

- Josh