ATTRIBUTE_WEAK

ATTRIBUTE_WEAK

[Jeffrey A Law]

It just occurred to me why you keep claiming ATTRIBUTE_WEAK is target
dependent.

It's the conditions under which ATTRIBUTE_WEAK is supported that is target
dependent.  Not the attribute itself or the fact that we want to use it
in a target file..

I think the way to go is to define/use TARGET_ATTRIBUTE_WEAK instead of
ATTRIBUTE_WEAK to help make this clear.  I still think this is fine for 
gansidecl.h in the mainline sources.

Sorry to have been so dense about this.
jeff

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> 
> It just occurred to me why you keep claiming ATTRIBUTE_WEAK is target
> dependent.
> 
> It's the conditions under which ATTRIBUTE_WEAK is supported that is target
> dependent.  Not the attribute itself or the fact that we want to use it
> in a target file..
> 
> I think the way to go is to define/use TARGET_ATTRIBUTE_WEAK instead of
> ATTRIBUTE_WEAK to help make this clear.  I still think this is fine for 
> gansidecl.h in the mainline sources.
> 
> Sorry to have been so dense about this.
> jeff
> 

Could you please show me how to use __attribute__ ((weak))? The code
below doesn't make "foo" weak. BTW,

#pragma weak foo

works fine.
 
Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
extern void foo () __attribute__ ((weak));

bar ()
{
  if (foo) foo ();
}

Re: ATTRIBUTE_WEAK

[Bill Currie]

H.J. Lu wrote:
> extern void foo () __attribute__ ((weak));
> 
> bar ()
> {
>   if (foo) foo ();
> }

Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
*define* a function, rather than reference it?  For your example, my
understanding says that the following is something closer to what's
intended:

-----
void __attribute__((weak)) foo()
{
}

-----
extern void foo();

bar()
{
  if (foo) foo();
}
-----

NOTE: I do not truly understand weak symbols, but I'm pretty sure it's
the definition that gets weakend (so it can be overridden) rather than
the reference (if the reference, would that be so the definition is
optional???).

Bill
-- 
Leave others their otherness

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> H.J. Lu wrote:
> > extern void foo () __attribute__ ((weak));
> > 
> > bar ()
> > {
> >   if (foo) foo ();
> > }
> 
> Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
> *define* a function, rather than reference it?  For your example, my
> understanding says that the following is something closer to what's
> intended:
> 
> -----
> void __attribute__((weak)) foo()
> {
> }
> 

That is not what we want. We want something like

#pragma weak foo
extern void foo ();

Can __attribute__ do it?


H.J.

Re: ATTRIBUTE_WEAK

[Matthias Urlichs]

Hi,

Bill Currie:
> Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
> *define* a function, rather than reference it?

"weak" has two meanings.
(a) don't complain if this gets overridden.
(b) don't complain if this doesn't exist at all.

Obviously, (a) refers to the definition, while (b) refers to the
'extern' declaration / reference.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
The problem with unwritten laws is that they're so hard to erase.

Re: ATTRIBUTE_WEAK

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]

On Feb 24, 1999, hjl@lucon.org (H.J. Lu) wrote:

> #pragma weak foo
> extern void foo ();

> Can __attribute__ do it?

AFAIK, weak applies only to definitions, not to external references.
What do you mean with a weak external reference, after all?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> On Feb 24, 1999, hjl@lucon.org (H.J. Lu) wrote:
> 
> > #pragma weak foo
> > extern void foo ();
> 
> > Can __attribute__ do it?
> 
> AFAIK, weak applies only to definitions, not to external references.

That is not true. The weak external reference is in the SVR4 ABI.

> What do you mean with a weak external reference, after all?
> 

Yes. That is how my patch works.


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

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> Hi,
> 
> Bill Currie:
> > Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
> > *define* a function, rather than reference it?
> 
> "weak" has two meanings.
> (a) don't complain if this gets overridden.
> (b) don't complain if this doesn't exist at all.
> 

More accurately:

(b) don't complain and set it to zero if this doesn't exist at all.

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

Re: ATTRIBUTE_WEAK

[Martin v. Loewis]

> Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when
> you *define* a function, rather than reference it?

That's what I thought as well. As it turns out, it has a meaning to
references, too. Referencing a weak symbol does not count as 'usage',
i.e. the one-definition-rule does not apply; the symbol does not need
to be defined at all.

Of course, this is an extension, and does not work on all object
formats.

Regards,
Martin

Re: ATTRIBUTE_WEAK

[Martin v. Loewis]

> AFAIK, weak applies only to definitions, not to external references.
> What do you mean with a weak external reference, after all?

HJ already provided an example:

#pragma weak foo
extern void foo ();

bar (){
  if (foo) foo ();
}

On i586-pc-linux-gnu, I get

bar:
        ...
	movl $foo,%eax
	testl %eax,%eax
	je .L3
	call foo
.L3:
        ...
	.weak	foo

I.e. a weak external does not need to be defined; if it is not
defined, it's address is 0. It's a cool feature, and I'd say not
supporting it with __attribute__ is a bug.

Regards,
Martin

Re: ATTRIBUTE_WEAK

[Franz Sirl]

Am Wed, 24 Feb 1999 schrieb Martin v. Loewis:
>> AFAIK, weak applies only to definitions, not to external references.
>> What do you mean with a weak external reference, after all?
>
>HJ already provided an example:
>
>#pragma weak foo
>extern void foo ();
>
>bar (){
>  if (foo) foo ();
>}
>
>On i586-pc-linux-gnu, I get
>
>bar:
>        ...
>	movl $foo,%eax
>	testl %eax,%eax
>	je .L3
>	call foo
>.L3:
>        ...
>	.weak	foo
>
>I.e. a weak external does not need to be defined; if it is not
>defined, it's address is 0. It's a cool feature, and I'd say not
>supporting it with __attribute__ is a bug.

This is what glibc-2.1 uses:

#  ifdef HAVE_ASM_WEAKEXT_DIRECTIVE
#   define weak_extern_asm(symbol) asm (".weakext " __SYMBOL_PREFIX #symbol);
#   define weak_alias_asm(original, alias) \
  asm (".weakext " __SYMBOL_PREFIX #alias ", " __SYMBOL_PREFIX #original);
#  else /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */
#   define weak_extern_asm(symbol)      asm (".weak " __SYMBOL_PREFIX #symbol);
#   define weak_alias_asm(original, alias) \
  asm (".weak " __SYMBOL_PREFIX #alias "\n" \
       __SYMBOL_PREFIX #alias " = " __SYMBOL_PREFIX #original);
#  endif /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */

#  define weak_alias(o, a) weak_alias_asm (o, a)
#  define weak_extern(symbol) weak_extern_asm (symbol)

Franz.

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> >
> >I.e. a weak external does not need to be defined; if it is not
> >defined, it's address is 0. It's a cool feature, and I'd say not
> >supporting it with __attribute__ is a bug.
> 
> This is what glibc-2.1 uses:
> 
> #  ifdef HAVE_ASM_WEAKEXT_DIRECTIVE
> #   define weak_extern_asm(symbol) asm (".weakext " __SYMBOL_PREFIX #symbol);
> #   define weak_alias_asm(original, alias) \
>   asm (".weakext " __SYMBOL_PREFIX #alias ", " __SYMBOL_PREFIX #original);
> #  else /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */
> #   define weak_extern_asm(symbol)      asm (".weak " __SYMBOL_PREFIX #symbol);
> #   define weak_alias_asm(original, alias) \
>   asm (".weak " __SYMBOL_PREFIX #alias "\n" \
>        __SYMBOL_PREFIX #alias " = " __SYMBOL_PREFIX #original);
> #  endif /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */
> 
> #  define weak_alias(o, a) weak_alias_asm (o, a)
> #  define weak_extern(symbol) weak_extern_asm (symbol)
> 
> 

IMHO, it is no better than

#pragma weak foo

I am looking for an attribute solution.


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

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> > Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when
> > you *define* a function, rather than reference it?
> 
> That's what I thought as well. As it turns out, it has a meaning to
> references, too. Referencing a weak symbol does not count as 'usage',
> i.e. the one-definition-rule does not apply; the symbol does not need
> to be defined at all.
> 
> Of course, this is an extension, and does not work on all object
> formats.
> 

It is the standard in the SVR4 ABI, aka ELF. We use it a lot in egcs,
see gthr-*.h and glibc.


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

Re: ATTRIBUTE_WEAK

[Joe Buck]

[ convoluted example from glibc2.1 deleted ]
> 
> IMHO, it is no better than
> 
> #pragma weak foo
> 
> I am looking for an attribute solution.

If no one can tell HJ how to produce a weak external reference with an
attribute, he should be permitted to use #pragma weak, IMHO, at least
until we come up with a clean, compact way to do it with attributes.

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < m10Fie3-000390C@ocean.lucon.org >you write:
  > Could you please show me how to use __attribute__ ((weak))? The code
  > below doesn't make "foo" weak. BTW,
  > 
  > #pragma weak foo
  > 
  > works fine.
  >  
  > Thanks.
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ---
  > extern void foo () __attribute__ ((weak));
  > 
  > bar ()
  > {
  >   if (foo) foo ();
  > }
Sigh.  There's a bug in our weak support.

It looks easy to fix, but I want to think about it for a little while.

It may be best to go ahead and use pragma for egcs-1.1.x and an attribute
in the mainline tree.

jeff

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 199902242334.PAA09446@atrus.synopsys.com >you write:
  > [ convoluted example from glibc2.1 deleted ]
  > > 
  > > IMHO, it is no better than
  > > 
  > > #pragma weak foo
  > > 
  > > I am looking for an attribute solution.
  > 
  > If no one can tell HJ how to produce a weak external reference with an
  > attribute, he should be permitted to use #pragma weak, IMHO, at least
  > until we come up with a clean, compact way to do it with attributes.
Agreed.

But the fix for the attribute weak support is so trivial that I'm just going
to fix it.  That way we can go ahead and use an attribute with egcs-1.1.2
as well as the mainline sources.


jeff

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < m10Fie3-000390C@ocean.lucon.org >you write:

  > Could you please show me how to use __attribute__ ((weak))? The code
  > below doesn't make "foo" weak. BTW,
  > 
[ ... ]
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ---
  > extern void foo () __attribute__ ((weak));
  > 
  > bar ()
  > {
  >   if (foo) foo ();
  > }
This is the right way to get a weak declaration.  It didn't work because  of
a trivial bug.  I've fixed that bug on the release branch (and will fix it
shortly in the mainline tree).

With the fix I get:

        .file   "foo.c"
        .version        "01.01"
gcc2_compiled.:
.text
        .align 4
.globl bar
        .type    bar,@function
bar:
        pushl %ebp
        movl %esp,%ebp
        movl $foo,%eax
        testl %eax,%eax
        je .L2
        call foo
.L2:
        movl %ebp,%esp
        popl %ebp
        ret
.Lfe1:
        .size    bar,.Lfe1-bar
        .weak   foo

Which is the same code I get if I use a #pragma instead.

jeff

Re: ATTRIBUTE_WEAK (drift, but...)

[Donn Terry]

I thought I'd wait until the primary focus of this discussion
had closed, which with Jeff's fixes, it appears to have done.

I could only sigh when I watched the rediscovery of a concept
that's been around for a very long time: that there are two
types of "weak" symbols.  The good folks (and it's well worth
looking at a lot of their work) at SDS (Scientific Data Systems)
later known as XDS (Xerox Data Systems) really understood their
business: they had good, solid, reliable solutions to this problem
(including the semantic confusion that "weak" causes) with
the concept of "secondary definition" and "secondary reference".
In fact, their object language was a real language and permitted
things (like the difference of two externals) that most so-called 
modern linkers can't handle (but which made for clean, elegant
assembler code).  (And a lot of other really nice solutions to problems
that continue to plague us, both in hardware design and software
design, even today.  They really thought the problems through.)

You'll notice I said "had".  I first got to know them in 1970,
but by 1976 or so, they were moribund.  Never did hear what
finally happened to them.  This is a piece of our past that
contains lessons for us that I wish more of us could see.  No,
they weren't perfect (and no, I wouldn't choose their OS
over Unix, but I'd sure like to see some concepts!), but it's
too bad that so much of what they did well has been lost
not only technically, but conceptually.  They were far ahead
of their time, and arguably ahead of our time in places.

Donn

P.S.  If you ever get a chance, and enjoy a good pun, read
their circa 1974 Fortran reference.  The only place I've ever
seen puns (and jokes) in a language referece that didn't
interfere with the readability of the document.  (But you
HAVE to be awake.)

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

TARGET_ATTRIBUTE_WEAK vs. pragma

[H.J. Lu]

> 
> 
>   In message < m10Fie3-000390C@ocean.lucon.org >you write:
> 
>   > Could you please show me how to use __attribute__ ((weak))? The code
>   > below doesn't make "foo" weak. BTW,
>   > 
> [ ... ]
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ---
>   > extern void foo () __attribute__ ((weak));
>   > 
>   > bar ()
>   > {
>   >   if (foo) foo ();
>   > }
> This is the right way to get a weak declaration.  It didn't work because  of
> a trivial bug.  I've fixed that bug on the release branch (and will fix it
> shortly in the mainline tree).
> 

While working on the TARGET_ATTRIBUTE_WEAK patch, I found a problem.
We want to make __register_frame_info and __deregister_frame_info
weak external in crtstuff.c. How do we do it with __attribute__?
We can only add TARGET_ATTRIBUTE_WEAK for crtstuff.c, but not for
frame.c. That means we have to

1. Put normal prototypes in frame.h and put another one in crtstuff.c.
They have to match. Or

2. In frame.h, we have

#ifndef TARGET_ATTRIBUTE_WEAK  
# if SUPPORTS_WEAK && defined(IN_CRTSTUFF)
#  define TARGET_ATTRIBUTE_WEAK __attribute__ ((weak))
# else
#  define TARGET_ATTRIBUTE_WEAK
# endif
#endif

extern void *__deregister_frame_info (void *)
				     TARGET_ATTRIBUTE_WEAK;

and in crtuff.c, we have

#define IN_CRTSTUFF
#include "frame.h"

Neither solution is as clean as putting "#pragma" in crtstuff.c. Does
anyone have a better solution? The more I look at it, the more I like
"#pragma weak".

Thanks.


H.J.

Re: TARGET_ATTRIBUTE_WEAK vs. pragma

[Jeffrey A Law]

  In message < m10G5mf-000390C@ocean.lucon.org >you write:
  > We want to make __register_frame_info and __deregister_frame_info
  > weak external in crtstuff.c.
Why?  If you fail to explain why, then there's no way for us to know if
what you're doing is actually right.  If you fail to explain why, this part
of the patch will be rejected.

If you're finding additional problems with your weak patch, then that indicates
to me that it probably is not something we should be putting into egcs-1.1.2.

But I'll hold off on a final decision until you actually explain the problem
you need to solve in crtstuff.c in more detail.

jeff

Re: TARGET_ATTRIBUTE_WEAK vs. pragma

[H.J. Lu]

> 
> 
>   In message < m10G5mf-000390C@ocean.lucon.org >you write:
>   > We want to make __register_frame_info and __deregister_frame_info
>   > weak external in crtstuff.c.
> Why?  If you fail to explain why, then there's no way for us to know if
> what you're doing is actually right.  If you fail to explain why, this part
> of the patch will be rejected.

Here we do again. I am enclosing my original patch here. Here is your
request:

1. Use an attribute instead of a pragmas.
2. Kill the unnecessary #ifdefs around the test for nonzero.  This code
is not time critical at all, so the extra if (funcname) isn't going to
have any noticable performance impact.

I did #2. Now I cannot find a solution for #1, which I like.

> 
> If you're finding additional problems with your weak patch, then that indicates
> to me that it probably is not something we should be putting into egcs-1.1.2.

The problem is I don't like the attribute solution I came up with.
Yes, it works. No, I don't like it. Do you have better solutions or
should I send you what I got?

Jeff, your original reply is at

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

Thanks.

H.J.
----
Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)

	* crtstuff.c (__register_frame_info, __deregister_frame_info):
	If SUPPORTS_WEAK is none zero, make them weak and check if they
	are none-zero before calling them.

--- ../../../import/egcs/gcc/crtstuff.c	Tue Jul 14 07:16:05 1998
+++ ./crtstuff.c	Fri Dec 11 08:59:56 1998
@@ -80,6 +80,11 @@
 #endif
 #if !defined (EH_FRAME_SECTION_ASM_OP) && defined (DWARF2_UNWIND_INFO) && defined(ASM_OUTPUT_SECTION_NAME)
 #define EH_FRAME_SECTION_ASM_OP	".section\t.eh_frame,\"aw\""
+
+#if SUPPORTS_WEAK
+#pragma weak __register_frame_info
+#pragma weak __deregister_frame_info
+#endif
 #endif
 
 #ifdef OBJECT_FORMAT_ELF
@@ -142,7 +147,10 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  if (__deregister_frame_info)
+#endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
   completed = 1;
 }
@@ -170,7 +178,10 @@
 frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -254,7 +265,10 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  if (__deregister_frame_info)
+#endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -266,7 +280,10 @@
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: TARGET_ATTRIBUTE_WEAK vs. pragma

[Jeffrey A Law]

  In message < m10G66o-000390C@ocean.lucon.org >you write:
  > > Why?  If you fail to explain why, then there's no way for us to know if
  > > what you're doing is actually right.  If you fail to explain why, this pa
  > > of the patch will be rejected.
  > 
  > Here we do again. I am enclosing my original patch here. Here is your
  > request:
Sorry.  I thought you were stating an additional requirement, not re-stating
the one we were already working on.

  > I did #2. Now I cannot find a solution for #1, which I like.
Send it anyway.  It may be the case that you do not like it, but it's still
a better solution, or it may be the case that someone can tweak it to make
it better.  We'll never know if you don't actually send the patch.

Or it may be the case that the pragmas really are better.

But until you send the attribute based patch we'll never know.

jeff

An egcs 1.1.2 patch for frame.h and crtstuff.c

[H.J. Lu]

> 
>   > I did #2. Now I cannot find a solution for #1, which I like.
> Send it anyway.  It may be the case that you do not like it, but it's still
> a better solution, or it may be the case that someone can tweak it to make
> it better.  We'll never know if you don't actually send the patch.
> 
> Or it may be the case that the pragmas really are better.
> 
> But until you send the attribute based patch we'll never know.
> 

Here it is. BTW, I am working on the libio patch now.


-- 
H.J. Lu (hjl@gnu.org)
---
Thu Feb 25 11:25:13 1999  H.J. Lu  (hjl@gnu.org)

	* frame.h (TARGET_ATTRIBUTE_WEAK): New. Use __attribute__ only
	if SUPPORTS_WEAK is not zero and IN_CRTSTUFF is defined.
	(__register_frame_info): Append TARGET_ATTRIBUTE_WEAK.
	(__deregister_frame_info): Likewise.

	* crtstuff.c (IN_CRTSTUFF): Defined before #include "frame.h".
	(__do_global_dtors_aux): Check if __deregister_frame_info is
	zero before calling it.
	(__do_global_dtors): Likewise.
	(frame_dummy): Check if __register_frame_info is zero before
	calling it.
	(__frame_dummy): Likewise.

--- ../../../import/egcs-1.1.x/egcs/gcc/frame.h	Fri Apr  3 08:34:57 1998
+++ ./frame.h	Thu Feb 25 10:45:46 1999
@@ -18,6 +18,14 @@ typedef struct frame_state
 #define REG_SAVED_OFFSET 1
 #define REG_SAVED_REG 2
 
+#ifndef TARGET_ATTRIBUTE_WEAK
+# if SUPPORTS_WEAK && defined(IN_CRTSTUFF)
+#  define TARGET_ATTRIBUTE_WEAK	__attribute__ ((weak))
+# else
+#  define TARGET_ATTRIBUTE_WEAK
+# endif
+#endif
+
 /* The representation for an "object" to be searched for frame unwind info.
    For targets with named sections, one object is an executable or shared
    library; for other targets, one object is one translation unit.
@@ -41,7 +49,8 @@ extern void __deregister_frame (void *);
 /* Called either from crtbegin.o or a static constructor to register the
    unwind info for an object or translation unit, respectively.  */
 
-extern void __register_frame_info (void *, struct object *);
+extern void __register_frame_info (void *, struct object *)
+				  TARGET_ATTRIBUTE_WEAK;
 
 /* Similar, but BEGIN is actually a pointer to a table of unwind entries
    for different translation units.  Called from the file generated by
@@ -50,7 +59,8 @@ extern void __register_frame_info_table 
 
 /* Called from crtend.o to deregister the unwind info for an object.  */
 
-extern void *__deregister_frame_info (void *);
+extern void *__deregister_frame_info (void *)
+				     TARGET_ATTRIBUTE_WEAK;
 
 /* Called from __throw to find the registers to restore for a given
    PC_TARGET.  The caller should allocate a local variable of `struct
--- ../../../import/egcs-1.1.x/egcs/gcc/crtstuff.c	Mon Jun  8 11:30:12 1998
+++ ./crtstuff.c	Thu Feb 25 10:47:16 1999
@@ -54,6 +54,7 @@ Boston, MA 02111-1307, USA.  */
 #include "tm.h"
 #include "defaults.h"
 #include <stddef.h>
+#define IN_CRTSTUFF
 #include "frame.h"
 
 /* Provide default definitions for the pseudo-ops used to switch to the
@@ -142,7 +143,8 @@ __do_global_dtors_aux ()
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+  if (__deregister_frame_info)
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
   completed = 1;
 }
@@ -170,7 +172,8 @@ static void
 frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  if (__register_frame_info)
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -254,7 +260,8 @@ __do_global_dtors ()
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+  if (__deregister_frame_info)
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -266,7 +273,8 @@ void
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  if (__register_frame_info)
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[Jeffrey A Law]

  In message < m10G6Wk-000390C@ocean.lucon.org >you write:
  > > 
  > >   > I did #2. Now I cannot find a solution for #1, which I like.
  > > Send it anyway.  It may be the case that you do not like it, but it's sti
  > ll
  > > a better solution, or it may be the case that someone can tweak it to mak
  > e
  > > it better.  We'll never know if you don't actually send the patch.
  > > 
  > > Or it may be the case that the pragmas really are better.
  > > 
  > > But until you send the attribute based patch we'll never know.
  > > 
  > 
  > Here it is. BTW, I am working on the libio patch now.

Thu Feb 25 11:25:13 1999  H.J. Lu  (hjl@gnu.org)

	* frame.h (TARGET_ATTRIBUTE_WEAK): New. Use __attribute__ only
	if SUPPORTS_WEAK is not zero and IN_CRTSTUFF is defined.
	(__register_frame_info): Append TARGET_ATTRIBUTE_WEAK.
	(__deregister_frame_info): Likewise.

	* crtstuff.c (IN_CRTSTUFF): Defined before #include "frame.h".
	(__do_global_dtors_aux): Check if __deregister_frame_info is
	zero before calling it.
	(__do_global_dtors): Likewise.
	(frame_dummy): Check if __register_frame_info is zero before
	calling it.
	(__frame_dummy): Likewise.
Thanks.  This looks pretty good.

I assume the IN_CRTSTUFF is needed because we only want the external
references in crtstuff to be weak, not the definitions in frame.c?

What parts of this patch are you not happy with?

jeff

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[H.J. Lu]

> 
> 
>   In message < m10G6Wk-000390C@ocean.lucon.org >you write:
>   > > 
>   > >   > I did #2. Now I cannot find a solution for #1, which I like.
>   > > Send it anyway.  It may be the case that you do not like it, but it's sti
>   > ll
>   > > a better solution, or it may be the case that someone can tweak it to mak
>   > e
>   > > it better.  We'll never know if you don't actually send the patch.
>   > > 
>   > > Or it may be the case that the pragmas really are better.
>   > > 
>   > > But until you send the attribute based patch we'll never know.
>   > > 
>   > 
>   > Here it is. BTW, I am working on the libio patch now.
> 
> Thu Feb 25 11:25:13 1999  H.J. Lu  (hjl@gnu.org)
> 
> 	* frame.h (TARGET_ATTRIBUTE_WEAK): New. Use __attribute__ only
> 	if SUPPORTS_WEAK is not zero and IN_CRTSTUFF is defined.
> 	(__register_frame_info): Append TARGET_ATTRIBUTE_WEAK.
> 	(__deregister_frame_info): Likewise.
> 
> 	* crtstuff.c (IN_CRTSTUFF): Defined before #include "frame.h".
> 	(__do_global_dtors_aux): Check if __deregister_frame_info is
> 	zero before calling it.
> 	(__do_global_dtors): Likewise.
> 	(frame_dummy): Check if __register_frame_info is zero before
> 	calling it.
> 	(__frame_dummy): Likewise.
> Thanks.  This looks pretty good.
> 
> I assume the IN_CRTSTUFF is needed because we only want the external
> references in crtstuff to be weak, not the definitions in frame.c?

Yes.

> 
> What parts of this patch are you not happy with?
> 

It has more codes than the pragma version and it touches frame.h. If
you find it is ok, that is fine with me.

Thanks.


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

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[Joern Rennecke]

> > I assume the IN_CRTSTUFF is needed because we only want the external
> > references in crtstuff to be weak, not the definitions in frame.c?
> 
> Yes.

How about adding a second declaration of __register_frame_info /
__deregister_frame_info in crtstuff.c ?  They would not need to have
argument prototypes.  Argument prototypes and attributes are cumulative,
i.e. when the second declaration is seen, the compiler maintains a new
merged symbol definition wich has the argument prototypes and the
merged attribute list.

Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

At 11:33 PM 2/24/99 -0700, you wrote:
>        .file   "foo.c"
>        .version        "01.01"
>gcc2_compiled.:
>..text
>        .align 4
>..globl bar
>        .type    bar,@function
>bar:
>        pushl %ebp
>        movl %esp,%ebp
>        movl $foo,%eax
>        testl %eax,%eax
>        je .L2
>        call foo
>..L2:
>        movl %ebp,%esp
>        popl %ebp
>        ret
>..Lfe1:
>        .size    bar,.Lfe1-bar
>        .weak   foo
>
>Which is the same code I get if I use a #pragma instead.

This code looks ill-formed to me. I've never heard of a pseudo-op "..text",
just ".text". Ditto "..globl"... If your version of egcs is producing asm
like that, I think weak symbol support is the least of your problems.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 3.0.6.32.19990226011105.00840100@pop.globalserve.net >you write:
  > This code looks ill-formed to me. I've never heard of a pseudo-op "..text",
  > just ".text". Ditto "..globl"... If your version of egcs is producing asm
  > like that, I think weak symbol support is the least of your problems.
Huh?  It only has one "." in the message I sent out.

It only has one "." in the archives.  http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html

Check your MUA, it's breaking things.


jeff

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[Jeffrey A Law]

  In message < 199902252106.VAA19396@phal.cygnus.co.uk >you write:
  > > > I assume the IN_CRTSTUFF is needed because we only want the external
  > > > references in crtstuff to be weak, not the definitions in frame.c?
  > > 
  > > Yes.
  > 
  > How about adding a second declaration of __register_frame_info /
  > __deregister_frame_info in crtstuff.c ?  They would not need to have
  > argument prototypes.  Argument prototypes and attributes are cumulative,
  > i.e. when the second declaration is seen, the compiler maintains a new
  > merged symbol definition wich has the argument prototypes and the
  > merged attribute list.
I think HJ's patch is cleaner than depending on this kind of non-obvious
behavior.  ie, HJ's patch makes it explicitly clear that when compiling
for crtstuff that we want the weak attribute.
jeff

Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

>Huh?  It only has one "." in the message I sent out.
>
>It only has one "." in the archives.
http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html
>
>Check your MUA, it's breaking things.

My MUA is perfectly normal. It must be the listserv, since there's no
reason why my mail client would be programmed to mutate some incoming
messages before displaying them. I have notified the egcs.cygnus.com
postmaster about this spurious character duplication issue.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 3.0.6.32.19990227221927.00850720@pop.globalserve.net >you write:
  > >Huh?  It only has one "." in the message I sent out.
  > >
  > >It only has one "." in the archives.
  > http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html
  > >
  > >Check your MUA, it's breaking things.
  > 
  > My MUA is perfectly normal. It must be the listserv, since there's no
  > reason why my mail client would be programmed to mutate some incoming
  > messages before displaying them. I have notified the egcs.cygnus.com
  > postmaster about this spurious character duplication issue.
Is anyone else seeing this problem?  I'm certainly not seeing it and it's
certainly fine in the archives.



jeff

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Zack Weinberg]

On Sat, 27 Feb 1999 20:38:12 -0700, Jeffrey A Law wrote:
>
>  In message < 3.0.6.32.19990227221927.00850720@pop.globalserve.net >you write:
>  > >Huh?  It only has one "." in the message I sent out.
>  > >
>  > >It only has one "." in the archives.
>  > http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html
>  > >
>  > >Check your MUA, it's breaking things.
>  > 
>  > My MUA is perfectly normal. It must be the listserv, since there's no
>  > reason why my mail client would be programmed to mutate some incoming
>  > messages before displaying them. I have notified the egcs.cygnus.com
>  > postmaster about this spurious character duplication issue.
>Is anyone else seeing this problem?  I'm certainly not seeing it and it's
>certainly fine in the archives.

I'm not seeing this either.

Dot duplication at the beginning of lines is normal - required in fact - for
the text following DATA in an SMTP exchange.  The receiving MTA is supposed
to strip out the dupes before delivering the message.  If Mr. Derbyshire is
seeing duplicate dots then his local MTA is malfunctioning.

The next line of this message consists of one dot.
.
Paul, you'll get two copies of this message - one direct, one via the list. 
I predict you'll see two dots on the line above in both copies.  Only if one
copy has one dot and the other two may you blame the list.

zw

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

At 10:54 PM 2/27/99 -0500, you wrote:
>Dot duplication at the beginning of lines is normal - required in fact - for
>the text following DATA in an SMTP exchange.

That makes absolutely no sense whatsoever, I hope you realize.

>The next line of this message consists of one dot.
>..

This sentence is a lie. :P

>Paul, you'll get two copies of this message - one direct, one via the list. 
>I predict you'll see two dots on the line above in both copies.  Only if one
>copy has one dot and the other two may you blame the list.

Well, there's nothing wrong with Eudora Light. Other than a bug involving
occasional hangs/GPFs, as normal with any Windows app...

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 3.0.6.32.19990227235315.008512c0@pop.globalserve.net >you write:
  > >The next line of this message consists of one dot.
  > >..
  > 
  > This sentence is a lie. :P
I got one dot, as expected on the original message, then two on your
reply (as expected).

The problem is on your side.  Take it up with whomever takes care of your
machines and drop this list from the discussion please.


jeff

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

At 09:57 PM 2/27/99 -0700, you wrote:
>The problem is on your side.  Take it up with whomever takes care of your
>machines and drop this list from the discussion please.

I have sent relevant information to postmaster@globalserve.net, since it is
presumably their SMTP server that should be stripping duplicate dots from
incoming mail before stowing it in the user's mail spool.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

An egcs 1.1.2 patch for frame.h and crtstuff.c

[H.J. Lu]

> 
>   > I did #2. Now I cannot find a solution for #1, which I like.
> Send it anyway.  It may be the case that you do not like it, but it's still
> a better solution, or it may be the case that someone can tweak it to make
> it better.  We'll never know if you don't actually send the patch.
> 
> Or it may be the case that the pragmas really are better.
> 
> But until you send the attribute based patch we'll never know.
> 

Here it is. BTW, I am working on the libio patch now.


-- 
H.J. Lu (hjl@gnu.org)
---
Thu Feb 25 11:25:13 1999  H.J. Lu  (hjl@gnu.org)

	* frame.h (TARGET_ATTRIBUTE_WEAK): New. Use __attribute__ only
	if SUPPORTS_WEAK is not zero and IN_CRTSTUFF is defined.
	(__register_frame_info): Append TARGET_ATTRIBUTE_WEAK.
	(__deregister_frame_info): Likewise.

	* crtstuff.c (IN_CRTSTUFF): Defined before #include "frame.h".
	(__do_global_dtors_aux): Check if __deregister_frame_info is
	zero before calling it.
	(__do_global_dtors): Likewise.
	(frame_dummy): Check if __register_frame_info is zero before
	calling it.
	(__frame_dummy): Likewise.

--- ../../../import/egcs-1.1.x/egcs/gcc/frame.h	Fri Apr  3 08:34:57 1998
+++ ./frame.h	Thu Feb 25 10:45:46 1999
@@ -18,6 +18,14 @@ typedef struct frame_state
 #define REG_SAVED_OFFSET 1
 #define REG_SAVED_REG 2
 
+#ifndef TARGET_ATTRIBUTE_WEAK
+# if SUPPORTS_WEAK && defined(IN_CRTSTUFF)
+#  define TARGET_ATTRIBUTE_WEAK	__attribute__ ((weak))
+# else
+#  define TARGET_ATTRIBUTE_WEAK
+# endif
+#endif
+
 /* The representation for an "object" to be searched for frame unwind info.
    For targets with named sections, one object is an executable or shared
    library; for other targets, one object is one translation unit.
@@ -41,7 +49,8 @@ extern void __deregister_frame (void *);
 /* Called either from crtbegin.o or a static constructor to register the
    unwind info for an object or translation unit, respectively.  */
 
-extern void __register_frame_info (void *, struct object *);
+extern void __register_frame_info (void *, struct object *)
+				  TARGET_ATTRIBUTE_WEAK;
 
 /* Similar, but BEGIN is actually a pointer to a table of unwind entries
    for different translation units.  Called from the file generated by
@@ -50,7 +59,8 @@ extern void __register_frame_info_table 
 
 /* Called from crtend.o to deregister the unwind info for an object.  */
 
-extern void *__deregister_frame_info (void *);
+extern void *__deregister_frame_info (void *)
+				     TARGET_ATTRIBUTE_WEAK;
 
 /* Called from __throw to find the registers to restore for a given
    PC_TARGET.  The caller should allocate a local variable of `struct
--- ../../../import/egcs-1.1.x/egcs/gcc/crtstuff.c	Mon Jun  8 11:30:12 1998
+++ ./crtstuff.c	Thu Feb 25 10:47:16 1999
@@ -54,6 +54,7 @@ Boston, MA 02111-1307, USA.  */
 #include "tm.h"
 #include "defaults.h"
 #include <stddef.h>
+#define IN_CRTSTUFF
 #include "frame.h"
 
 /* Provide default definitions for the pseudo-ops used to switch to the
@@ -142,7 +143,8 @@ __do_global_dtors_aux ()
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+  if (__deregister_frame_info)
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
   completed = 1;
 }
@@ -170,7 +172,8 @@ static void
 frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  if (__register_frame_info)
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -254,7 +260,8 @@ __do_global_dtors ()
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+  if (__deregister_frame_info)
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -266,7 +273,8 @@ void
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+  if (__register_frame_info)
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

At 09:57 PM 2/27/99 -0700, you wrote:
>The problem is on your side.  Take it up with whomever takes care of your
>machines and drop this list from the discussion please.

I have sent relevant information to postmaster@globalserve.net, since it is
presumably their SMTP server that should be stripping duplicate dots from
incoming mail before stowing it in the user's mail spool.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: TARGET_ATTRIBUTE_WEAK vs. pragma

[Jeffrey A Law]

  In message < m10G66o-000390C@ocean.lucon.org >you write:
  > > Why?  If you fail to explain why, then there's no way for us to know if
  > > what you're doing is actually right.  If you fail to explain why, this pa
  > > of the patch will be rejected.
  > 
  > Here we do again. I am enclosing my original patch here. Here is your
  > request:
Sorry.  I thought you were stating an additional requirement, not re-stating
the one we were already working on.

  > I did #2. Now I cannot find a solution for #1, which I like.
Send it anyway.  It may be the case that you do not like it, but it's still
a better solution, or it may be the case that someone can tweak it to make
it better.  We'll never know if you don't actually send the patch.

Or it may be the case that the pragmas really are better.

But until you send the attribute based patch we'll never know.

jeff

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Zack Weinberg]

On Sat, 27 Feb 1999 20:38:12 -0700, Jeffrey A Law wrote:
>
>  In message < 3.0.6.32.19990227221927.00850720@pop.globalserve.net >you write:
>  > >Huh?  It only has one "." in the message I sent out.
>  > >
>  > >It only has one "." in the archives.
>  > http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html
>  > >
>  > >Check your MUA, it's breaking things.
>  > 
>  > My MUA is perfectly normal. It must be the listserv, since there's no
>  > reason why my mail client would be programmed to mutate some incoming
>  > messages before displaying them. I have notified the egcs.cygnus.com
>  > postmaster about this spurious character duplication issue.
>Is anyone else seeing this problem?  I'm certainly not seeing it and it's
>certainly fine in the archives.

I'm not seeing this either.

Dot duplication at the beginning of lines is normal - required in fact - for
the text following DATA in an SMTP exchange.  The receiving MTA is supposed
to strip out the dupes before delivering the message.  If Mr. Derbyshire is
seeing duplicate dots then his local MTA is malfunctioning.

The next line of this message consists of one dot.
.
Paul, you'll get two copies of this message - one direct, one via the list. 
I predict you'll see two dots on the line above in both copies.  Only if one
copy has one dot and the other two may you blame the list.

zw

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> On Feb 24, 1999, hjl@lucon.org (H.J. Lu) wrote:
> 
> > #pragma weak foo
> > extern void foo ();
> 
> > Can __attribute__ do it?
> 
> AFAIK, weak applies only to definitions, not to external references.

That is not true. The weak external reference is in the SVR4 ABI.

> What do you mean with a weak external reference, after all?
> 

Yes. That is how my patch works.


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

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[Joern Rennecke]

> > I assume the IN_CRTSTUFF is needed because we only want the external
> > references in crtstuff to be weak, not the definitions in frame.c?
> 
> Yes.

How about adding a second declaration of __register_frame_info /
__deregister_frame_info in crtstuff.c ?  They would not need to have
argument prototypes.  Argument prototypes and attributes are cumulative,
i.e. when the second declaration is seen, the compiler maintains a new
merged symbol definition wich has the argument prototypes and the
merged attribute list.

Re: ATTRIBUTE_WEAK

[Franz Sirl]

Am Wed, 24 Feb 1999 schrieb Martin v. Loewis:
>> AFAIK, weak applies only to definitions, not to external references.
>> What do you mean with a weak external reference, after all?
>
>HJ already provided an example:
>
>#pragma weak foo
>extern void foo ();
>
>bar (){
>  if (foo) foo ();
>}
>
>On i586-pc-linux-gnu, I get
>
>bar:
>        ...
>	movl $foo,%eax
>	testl %eax,%eax
>	je .L3
>	call foo
>.L3:
>        ...
>	.weak	foo
>
>I.e. a weak external does not need to be defined; if it is not
>defined, it's address is 0. It's a cool feature, and I'd say not
>supporting it with __attribute__ is a bug.

This is what glibc-2.1 uses:

#  ifdef HAVE_ASM_WEAKEXT_DIRECTIVE
#   define weak_extern_asm(symbol) asm (".weakext " __SYMBOL_PREFIX #symbol);
#   define weak_alias_asm(original, alias) \
  asm (".weakext " __SYMBOL_PREFIX #alias ", " __SYMBOL_PREFIX #original);
#  else /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */
#   define weak_extern_asm(symbol)      asm (".weak " __SYMBOL_PREFIX #symbol);
#   define weak_alias_asm(original, alias) \
  asm (".weak " __SYMBOL_PREFIX #alias "\n" \
       __SYMBOL_PREFIX #alias " = " __SYMBOL_PREFIX #original);
#  endif /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */

#  define weak_alias(o, a) weak_alias_asm (o, a)
#  define weak_extern(symbol) weak_extern_asm (symbol)

Franz.

Re: ATTRIBUTE_WEAK

[Bill Currie]

H.J. Lu wrote:
> extern void foo () __attribute__ ((weak));
> 
> bar ()
> {
>   if (foo) foo ();
> }

Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
*define* a function, rather than reference it?  For your example, my
understanding says that the following is something closer to what's
intended:

-----
void __attribute__((weak)) foo()
{
}

-----
extern void foo();

bar()
{
  if (foo) foo();
}
-----

NOTE: I do not truly understand weak symbols, but I'm pretty sure it's
the definition that gets weakend (so it can be overridden) rather than
the reference (if the reference, would that be so the definition is
optional???).

Bill
-- 
Leave others their otherness

Re: ATTRIBUTE_WEAK

[Martin v. Loewis]

> Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when
> you *define* a function, rather than reference it?

That's what I thought as well. As it turns out, it has a meaning to
references, too. Referencing a weak symbol does not count as 'usage',
i.e. the one-definition-rule does not apply; the symbol does not need
to be defined at all.

Of course, this is an extension, and does not work on all object
formats.

Regards,
Martin

Re: ATTRIBUTE_WEAK

[Matthias Urlichs]

Hi,

Bill Currie:
> Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
> *define* a function, rather than reference it?

"weak" has two meanings.
(a) don't complain if this gets overridden.
(b) don't complain if this doesn't exist at all.

Obviously, (a) refers to the definition, while (b) refers to the
'extern' declaration / reference.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.    |      http://www.noris.de/~smurf/
-- 
The problem with unwritten laws is that they're so hard to erase.

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[Jeffrey A Law]

  In message < m10G6Wk-000390C@ocean.lucon.org >you write:
  > > 
  > >   > I did #2. Now I cannot find a solution for #1, which I like.
  > > Send it anyway.  It may be the case that you do not like it, but it's sti
  > ll
  > > a better solution, or it may be the case that someone can tweak it to mak
  > e
  > > it better.  We'll never know if you don't actually send the patch.
  > > 
  > > Or it may be the case that the pragmas really are better.
  > > 
  > > But until you send the attribute based patch we'll never know.
  > > 
  > 
  > Here it is. BTW, I am working on the libio patch now.

Thu Feb 25 11:25:13 1999  H.J. Lu  (hjl@gnu.org)

	* frame.h (TARGET_ATTRIBUTE_WEAK): New. Use __attribute__ only
	if SUPPORTS_WEAK is not zero and IN_CRTSTUFF is defined.
	(__register_frame_info): Append TARGET_ATTRIBUTE_WEAK.
	(__deregister_frame_info): Likewise.

	* crtstuff.c (IN_CRTSTUFF): Defined before #include "frame.h".
	(__do_global_dtors_aux): Check if __deregister_frame_info is
	zero before calling it.
	(__do_global_dtors): Likewise.
	(frame_dummy): Check if __register_frame_info is zero before
	calling it.
	(__frame_dummy): Likewise.
Thanks.  This looks pretty good.

I assume the IN_CRTSTUFF is needed because we only want the external
references in crtstuff to be weak, not the definitions in frame.c?

What parts of this patch are you not happy with?

jeff

Re: ATTRIBUTE_WEAK (drift, but...)

[Donn Terry]

I thought I'd wait until the primary focus of this discussion
had closed, which with Jeff's fixes, it appears to have done.

I could only sigh when I watched the rediscovery of a concept
that's been around for a very long time: that there are two
types of "weak" symbols.  The good folks (and it's well worth
looking at a lot of their work) at SDS (Scientific Data Systems)
later known as XDS (Xerox Data Systems) really understood their
business: they had good, solid, reliable solutions to this problem
(including the semantic confusion that "weak" causes) with
the concept of "secondary definition" and "secondary reference".
In fact, their object language was a real language and permitted
things (like the difference of two externals) that most so-called 
modern linkers can't handle (but which made for clean, elegant
assembler code).  (And a lot of other really nice solutions to problems
that continue to plague us, both in hardware design and software
design, even today.  They really thought the problems through.)

You'll notice I said "had".  I first got to know them in 1970,
but by 1976 or so, they were moribund.  Never did hear what
finally happened to them.  This is a piece of our past that
contains lessons for us that I wish more of us could see.  No,
they weren't perfect (and no, I wouldn't choose their OS
over Unix, but I'd sure like to see some concepts!), but it's
too bad that so much of what they did well has been lost
not only technically, but conceptually.  They were far ahead
of their time, and arguably ahead of our time in places.

Donn

P.S.  If you ever get a chance, and enjoy a good pun, read
their circa 1974 Fortran reference.  The only place I've ever
seen puns (and jokes) in a language referece that didn't
interfere with the readability of the document.  (But you
HAVE to be awake.)

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> 
> It just occurred to me why you keep claiming ATTRIBUTE_WEAK is target
> dependent.
> 
> It's the conditions under which ATTRIBUTE_WEAK is supported that is target
> dependent.  Not the attribute itself or the fact that we want to use it
> in a target file..
> 
> I think the way to go is to define/use TARGET_ATTRIBUTE_WEAK instead of
> ATTRIBUTE_WEAK to help make this clear.  I still think this is fine for 
> gansidecl.h in the mainline sources.
> 
> Sorry to have been so dense about this.
> jeff
> 

Could you please show me how to use __attribute__ ((weak))? The code
below doesn't make "foo" weak. BTW,

#pragma weak foo

works fine.
 
Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
extern void foo () __attribute__ ((weak));

bar ()
{
  if (foo) foo ();
}

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 3.0.6.32.19990226011105.00840100@pop.globalserve.net >you write:
  > This code looks ill-formed to me. I've never heard of a pseudo-op "..text",
  > just ".text". Ditto "..globl"... If your version of egcs is producing asm
  > like that, I think weak symbol support is the least of your problems.
Huh?  It only has one "." in the message I sent out.

It only has one "." in the archives.  http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html

Check your MUA, it's breaking things.


jeff

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[Jeffrey A Law]

  In message < 199902252106.VAA19396@phal.cygnus.co.uk >you write:
  > > > I assume the IN_CRTSTUFF is needed because we only want the external
  > > > references in crtstuff to be weak, not the definitions in frame.c?
  > > 
  > > Yes.
  > 
  > How about adding a second declaration of __register_frame_info /
  > __deregister_frame_info in crtstuff.c ?  They would not need to have
  > argument prototypes.  Argument prototypes and attributes are cumulative,
  > i.e. when the second declaration is seen, the compiler maintains a new
  > merged symbol definition wich has the argument prototypes and the
  > merged attribute list.
I think HJ's patch is cleaner than depending on this kind of non-obvious
behavior.  ie, HJ's patch makes it explicitly clear that when compiling
for crtstuff that we want the weak attribute.
jeff

Re: TARGET_ATTRIBUTE_WEAK vs. pragma

[H.J. Lu]

> 
> 
>   In message < m10G5mf-000390C@ocean.lucon.org >you write:
>   > We want to make __register_frame_info and __deregister_frame_info
>   > weak external in crtstuff.c.
> Why?  If you fail to explain why, then there's no way for us to know if
> what you're doing is actually right.  If you fail to explain why, this part
> of the patch will be rejected.

Here we do again. I am enclosing my original patch here. Here is your
request:

1. Use an attribute instead of a pragmas.
2. Kill the unnecessary #ifdefs around the test for nonzero.  This code
is not time critical at all, so the extra if (funcname) isn't going to
have any noticable performance impact.

I did #2. Now I cannot find a solution for #1, which I like.

> 
> If you're finding additional problems with your weak patch, then that indicates
> to me that it probably is not something we should be putting into egcs-1.1.2.

The problem is I don't like the attribute solution I came up with.
Yes, it works. No, I don't like it. Do you have better solutions or
should I send you what I got?

Jeff, your original reply is at

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

Thanks.

H.J.
----
Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)

	* crtstuff.c (__register_frame_info, __deregister_frame_info):
	If SUPPORTS_WEAK is none zero, make them weak and check if they
	are none-zero before calling them.

--- ../../../import/egcs/gcc/crtstuff.c	Tue Jul 14 07:16:05 1998
+++ ./crtstuff.c	Fri Dec 11 08:59:56 1998
@@ -80,6 +80,11 @@
 #endif
 #if !defined (EH_FRAME_SECTION_ASM_OP) && defined (DWARF2_UNWIND_INFO) && defined(ASM_OUTPUT_SECTION_NAME)
 #define EH_FRAME_SECTION_ASM_OP	".section\t.eh_frame,\"aw\""
+
+#if SUPPORTS_WEAK
+#pragma weak __register_frame_info
+#pragma weak __deregister_frame_info
+#endif
 #endif
 
 #ifdef OBJECT_FORMAT_ELF
@@ -142,7 +147,10 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  if (__deregister_frame_info)
+#endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
   completed = 1;
 }
@@ -170,7 +178,10 @@
 frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -254,7 +265,10 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  if (__deregister_frame_info)
+#endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -266,7 +280,10 @@
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: ATTRIBUTE_WEAK

[Martin v. Loewis]

> AFAIK, weak applies only to definitions, not to external references.
> What do you mean with a weak external reference, after all?

HJ already provided an example:

#pragma weak foo
extern void foo ();

bar (){
  if (foo) foo ();
}

On i586-pc-linux-gnu, I get

bar:
        ...
	movl $foo,%eax
	testl %eax,%eax
	je .L3
	call foo
.L3:
        ...
	.weak	foo

I.e. a weak external does not need to be defined; if it is not
defined, it's address is 0. It's a cool feature, and I'd say not
supporting it with __attribute__ is a bug.

Regards,
Martin

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < m10Fie3-000390C@ocean.lucon.org >you write:

  > Could you please show me how to use __attribute__ ((weak))? The code
  > below doesn't make "foo" weak. BTW,
  > 
[ ... ]
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ---
  > extern void foo () __attribute__ ((weak));
  > 
  > bar ()
  > {
  >   if (foo) foo ();
  > }
This is the right way to get a weak declaration.  It didn't work because  of
a trivial bug.  I've fixed that bug on the release branch (and will fix it
shortly in the mainline tree).

With the fix I get:

        .file   "foo.c"
        .version        "01.01"
gcc2_compiled.:
.text
        .align 4
.globl bar
        .type    bar,@function
bar:
        pushl %ebp
        movl %esp,%ebp
        movl $foo,%eax
        testl %eax,%eax
        je .L2
        call foo
.L2:
        movl %ebp,%esp
        popl %ebp
        ret
.Lfe1:
        .size    bar,.Lfe1-bar
        .weak   foo

Which is the same code I get if I use a #pragma instead.

jeff

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 199902242334.PAA09446@atrus.synopsys.com >you write:
  > [ convoluted example from glibc2.1 deleted ]
  > > 
  > > IMHO, it is no better than
  > > 
  > > #pragma weak foo
  > > 
  > > I am looking for an attribute solution.
  > 
  > If no one can tell HJ how to produce a weak external reference with an
  > attribute, he should be permitted to use #pragma weak, IMHO, at least
  > until we come up with a clean, compact way to do it with attributes.
Agreed.

But the fix for the attribute weak support is so trivial that I'm just going
to fix it.  That way we can go ahead and use an attribute with egcs-1.1.2
as well as the mainline sources.


jeff

Re: An egcs 1.1.2 patch for frame.h and crtstuff.c

[H.J. Lu]

> 
> 
>   In message < m10G6Wk-000390C@ocean.lucon.org >you write:
>   > > 
>   > >   > I did #2. Now I cannot find a solution for #1, which I like.
>   > > Send it anyway.  It may be the case that you do not like it, but it's sti
>   > ll
>   > > a better solution, or it may be the case that someone can tweak it to mak
>   > e
>   > > it better.  We'll never know if you don't actually send the patch.
>   > > 
>   > > Or it may be the case that the pragmas really are better.
>   > > 
>   > > But until you send the attribute based patch we'll never know.
>   > > 
>   > 
>   > Here it is. BTW, I am working on the libio patch now.
> 
> Thu Feb 25 11:25:13 1999  H.J. Lu  (hjl@gnu.org)
> 
> 	* frame.h (TARGET_ATTRIBUTE_WEAK): New. Use __attribute__ only
> 	if SUPPORTS_WEAK is not zero and IN_CRTSTUFF is defined.
> 	(__register_frame_info): Append TARGET_ATTRIBUTE_WEAK.
> 	(__deregister_frame_info): Likewise.
> 
> 	* crtstuff.c (IN_CRTSTUFF): Defined before #include "frame.h".
> 	(__do_global_dtors_aux): Check if __deregister_frame_info is
> 	zero before calling it.
> 	(__do_global_dtors): Likewise.
> 	(frame_dummy): Check if __register_frame_info is zero before
> 	calling it.
> 	(__frame_dummy): Likewise.
> Thanks.  This looks pretty good.
> 
> I assume the IN_CRTSTUFF is needed because we only want the external
> references in crtstuff to be weak, not the definitions in frame.c?

Yes.

> 
> What parts of this patch are you not happy with?
> 

It has more codes than the pragma version and it touches frame.h. If
you find it is ok, that is fine with me.

Thanks.


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

Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

At 11:33 PM 2/24/99 -0700, you wrote:
>        .file   "foo.c"
>        .version        "01.01"
>gcc2_compiled.:
>..text
>        .align 4
>..globl bar
>        .type    bar,@function
>bar:
>        pushl %ebp
>        movl %esp,%ebp
>        movl $foo,%eax
>        testl %eax,%eax
>        je .L2
>        call foo
>..L2:
>        movl %ebp,%esp
>        popl %ebp
>        ret
>..Lfe1:
>        .size    bar,.Lfe1-bar
>        .weak   foo
>
>Which is the same code I get if I use a #pragma instead.

This code looks ill-formed to me. I've never heard of a pseudo-op "..text",
just ".text". Ditto "..globl"... If your version of egcs is producing asm
like that, I think weak symbol support is the least of your problems.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: ATTRIBUTE_WEAK

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Feb 24, 1999, hjl@lucon.org (H.J. Lu) wrote:

> #pragma weak foo
> extern void foo ();

> Can __attribute__ do it?

AFAIK, weak applies only to definitions, not to external references.
What do you mean with a weak external reference, after all?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> > Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when
> > you *define* a function, rather than reference it?
> 
> That's what I thought as well. As it turns out, it has a meaning to
> references, too. Referencing a weak symbol does not count as 'usage',
> i.e. the one-definition-rule does not apply; the symbol does not need
> to be defined at all.
> 
> Of course, this is an extension, and does not work on all object
> formats.
> 

It is the standard in the SVR4 ABI, aka ELF. We use it a lot in egcs,
see gthr-*.h and glibc.


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

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> Hi,
> 
> Bill Currie:
> > Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
> > *define* a function, rather than reference it?
> 
> "weak" has two meanings.
> (a) don't complain if this gets overridden.
> (b) don't complain if this doesn't exist at all.
> 

More accurately:

(b) don't complain and set it to zero if this doesn't exist at all.

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

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 3.0.6.32.19990227221927.00850720@pop.globalserve.net >you write:
  > >Huh?  It only has one "." in the message I sent out.
  > >
  > >It only has one "." in the archives.
  > http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html
  > >
  > >Check your MUA, it's breaking things.
  > 
  > My MUA is perfectly normal. It must be the listserv, since there's no
  > reason why my mail client would be programmed to mutate some incoming
  > messages before displaying them. I have notified the egcs.cygnus.com
  > postmaster about this spurious character duplication issue.
Is anyone else seeing this problem?  I'm certainly not seeing it and it's
certainly fine in the archives.



jeff

Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < m10Fie3-000390C@ocean.lucon.org >you write:
  > Could you please show me how to use __attribute__ ((weak))? The code
  > below doesn't make "foo" weak. BTW,
  > 
  > #pragma weak foo
  > 
  > works fine.
  >  
  > Thanks.
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ---
  > extern void foo () __attribute__ ((weak));
  > 
  > bar ()
  > {
  >   if (foo) foo ();
  > }
Sigh.  There's a bug in our weak support.

It looks easy to fix, but I want to think about it for a little while.

It may be best to go ahead and use pragma for egcs-1.1.x and an attribute
in the mainline tree.

jeff

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> 
> H.J. Lu wrote:
> > extern void foo () __attribute__ ((weak));
> > 
> > bar ()
> > {
> >   if (foo) foo ();
> > }
> 
> Correct me if I'm wrong, but isn't __attribute__ ((weak)) for when you
> *define* a function, rather than reference it?  For your example, my
> understanding says that the following is something closer to what's
> intended:
> 
> -----
> void __attribute__((weak)) foo()
> {
> }
> 

That is not what we want. We want something like

#pragma weak foo
extern void foo ();

Can __attribute__ do it?


H.J.

TARGET_ATTRIBUTE_WEAK vs. pragma

[H.J. Lu]

> 
> 
>   In message < m10Fie3-000390C@ocean.lucon.org >you write:
> 
>   > Could you please show me how to use __attribute__ ((weak))? The code
>   > below doesn't make "foo" weak. BTW,
>   > 
> [ ... ]
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ---
>   > extern void foo () __attribute__ ((weak));
>   > 
>   > bar ()
>   > {
>   >   if (foo) foo ();
>   > }
> This is the right way to get a weak declaration.  It didn't work because  of
> a trivial bug.  I've fixed that bug on the release branch (and will fix it
> shortly in the mainline tree).
> 

While working on the TARGET_ATTRIBUTE_WEAK patch, I found a problem.
We want to make __register_frame_info and __deregister_frame_info
weak external in crtstuff.c. How do we do it with __attribute__?
We can only add TARGET_ATTRIBUTE_WEAK for crtstuff.c, but not for
frame.c. That means we have to

1. Put normal prototypes in frame.h and put another one in crtstuff.c.
They have to match. Or

2. In frame.h, we have

#ifndef TARGET_ATTRIBUTE_WEAK  
# if SUPPORTS_WEAK && defined(IN_CRTSTUFF)
#  define TARGET_ATTRIBUTE_WEAK __attribute__ ((weak))
# else
#  define TARGET_ATTRIBUTE_WEAK
# endif
#endif

extern void *__deregister_frame_info (void *)
				     TARGET_ATTRIBUTE_WEAK;

and in crtuff.c, we have

#define IN_CRTSTUFF
#include "frame.h"

Neither solution is as clean as putting "#pragma" in crtstuff.c. Does
anyone have a better solution? The more I look at it, the more I like
"#pragma weak".

Thanks.


H.J.

Re: ATTRIBUTE_WEAK

[Joe Buck]

[ convoluted example from glibc2.1 deleted ]
> 
> IMHO, it is no better than
> 
> #pragma weak foo
> 
> I am looking for an attribute solution.

If no one can tell HJ how to produce a weak external reference with an
attribute, he should be permitted to use #pragma weak, IMHO, at least
until we come up with a clean, compact way to do it with attributes.

Re: ATTRIBUTE_WEAK

[H.J. Lu]

> >
> >I.e. a weak external does not need to be defined; if it is not
> >defined, it's address is 0. It's a cool feature, and I'd say not
> >supporting it with __attribute__ is a bug.
> 
> This is what glibc-2.1 uses:
> 
> #  ifdef HAVE_ASM_WEAKEXT_DIRECTIVE
> #   define weak_extern_asm(symbol) asm (".weakext " __SYMBOL_PREFIX #symbol);
> #   define weak_alias_asm(original, alias) \
>   asm (".weakext " __SYMBOL_PREFIX #alias ", " __SYMBOL_PREFIX #original);
> #  else /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */
> #   define weak_extern_asm(symbol)      asm (".weak " __SYMBOL_PREFIX #symbol);
> #   define weak_alias_asm(original, alias) \
>   asm (".weak " __SYMBOL_PREFIX #alias "\n" \
>        __SYMBOL_PREFIX #alias " = " __SYMBOL_PREFIX #original);
> #  endif /* ! HAVE_ASM_WEAKEXT_DIRECTIVE */
> 
> #  define weak_alias(o, a) weak_alias_asm (o, a)
> #  define weak_extern(symbol) weak_extern_asm (symbol)
> 
> 

IMHO, it is no better than

#pragma weak foo

I am looking for an attribute solution.


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

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Jeffrey A Law]

  In message < 3.0.6.32.19990227235315.008512c0@pop.globalserve.net >you write:
  > >The next line of this message consists of one dot.
  > >..
  > 
  > This sentence is a lie. :P
I got one dot, as expected on the original message, then two on your
reply (as expected).

The problem is on your side.  Take it up with whomever takes care of your
machines and drop this list from the discussion please.


jeff

Re: Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

At 10:54 PM 2/27/99 -0500, you wrote:
>Dot duplication at the beginning of lines is normal - required in fact - for
>the text following DATA in an SMTP exchange.

That makes absolutely no sense whatsoever, I hope you realize.

>The next line of this message consists of one dot.
>..

This sentence is a lie. :P

>Paul, you'll get two copies of this message - one direct, one via the list. 
>I predict you'll see two dots on the line above in both copies.  Only if one
>copy has one dot and the other two may you blame the list.

Well, there's nothing wrong with Eudora Light. Other than a bug involving
occasional hangs/GPFs, as normal with any Windows app...

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

ATTRIBUTE_WEAK

[Jeffrey A Law]

It just occurred to me why you keep claiming ATTRIBUTE_WEAK is target
dependent.

It's the conditions under which ATTRIBUTE_WEAK is supported that is target
dependent.  Not the attribute itself or the fact that we want to use it
in a target file..

I think the way to go is to define/use TARGET_ATTRIBUTE_WEAK instead of
ATTRIBUTE_WEAK to help make this clear.  I still think this is fine for 
gansidecl.h in the mainline sources.

Sorry to have been so dense about this.
jeff

Re: TARGET_ATTRIBUTE_WEAK vs. pragma

[Jeffrey A Law]

  In message < m10G5mf-000390C@ocean.lucon.org >you write:
  > We want to make __register_frame_info and __deregister_frame_info
  > weak external in crtstuff.c.
Why?  If you fail to explain why, then there's no way for us to know if
what you're doing is actually right.  If you fail to explain why, this part
of the patch will be rejected.

If you're finding additional problems with your weak patch, then that indicates
to me that it probably is not something we should be putting into egcs-1.1.2.

But I'll hold off on a final decision until you actually explain the problem
you need to solve in crtstuff.c in more detail.

jeff

Mail transfer bogons, was Re: ATTRIBUTE_WEAK

[Paul Derbyshire]

>Huh?  It only has one "." in the message I sent out.
>
>It only has one "." in the archives.
http://egcs.cygnus.com/ml/egcs/1999-02/msg01238.html
>
>Check your MUA, it's breaking things.

My MUA is perfectly normal. It must be the listserv, since there's no
reason why my mail client would be programmed to mutate some incoming
messages before displaying them. I have notified the egcs.cygnus.com
postmaster about this spurious character duplication issue.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|