Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Should linker merge symbol visibility for weak symbol
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  5 messages - Collapse all  -  Translate all to Translated (View all originals)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
H.J.  
View profile  
 More options Jan 15 2010, 9:04 am
From: "H.J." <hjl.to...@gmail.com>
Date: Fri, 15 Jan 2010 06:04:12 -0800 (PST)
Local: Fri, Jan 15 2010 9:04 am
Subject: Should linker merge symbol visibility for weak symbol
There are

---
extern int foo (void) __attribute__((weak,__visibility__ ("hidden")));

int
foo (void)
{
  return 1;

}

int
bar (void)
{
  return foo ();
}

---

where "foo" is marked as weak and hidden. Can a compiler assume
that linker will make "foo" hidden even when there is a non-week
definition of "foo" in another relocatable file?


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Ian Lance Taylor  
View profile  
 More options Jan 15 2010, 10:23 am
From: Ian Lance Taylor <ianlancetay...@gmail.com>
Date: Fri, 15 Jan 2010 07:23:42 -0800
Local: Fri, Jan 15 2010 10:23 am
Subject: Re: Should linker merge symbol visibility for weak symbol

"H.J." <hjl.to...@gmail.com> writes:
> Can a compiler assume
> that linker will make "foo" hidden even when there is a non-week
> definition of "foo" in another relocatable file?

The ELF ABI says "If different visibility attributes are specified for
distinct references to or definitions of a symbol, the most
constraining visibility attribute must be propagated to the resolving
symbol in the linked object."  Since it specifically says "distinct
definitions" I assumed that that meant that visibility would propagate
from a weak definition to a strong definition.

I can't really tell whether that is a good idea or not.  It's hard for
me to imagine a case where one would reasonably want a weak protected
definition combined with a strong definition with default visibility.

Ian


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
H.J.  
View profile  
 More options Jan 15 2010, 11:48 am
From: "H.J." <hjl.to...@gmail.com>
Date: Fri, 15 Jan 2010 08:48:32 -0800 (PST)
Local: Fri, Jan 15 2010 11:48 am
Subject: Re: Should linker merge symbol visibility for weak symbol
On Jan 15, 7:23 am, Ian Lance Taylor <ianlancetay...@gmail.com> wrote:

> "H.J." <hjl.to...@gmail.com> writes:
> > Can a compiler assume
> > that linker will make "foo" hidden even when there is a non-week
> > definition of "foo" in another relocatable file?

> The ELF ABI says "If different visibility attributes are specified for
> distinct references to or definitions of a symbol, the most
> constraining visibility attribute must be propagated to the resolving
> symbol in the linked object."  Since it specifically says "distinct
> definitions" I assumed that that meant that visibility would propagate
> from a weak definition to a strong definition.

I thought so myself. I assume gold does it. What do other ELF
linkers do?

H.J.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Rod Evans  
View profile  
 More options Jan 15 2010, 12:15 pm
From: Rod Evans <Rod.Ev...@sun.com>
Date: Fri, 15 Jan 2010 09:15:39 -0800
Local: Fri, Jan 15 2010 12:15 pm
Subject: Re: Should linker merge symbol visibility for weak symbol
On 01/15/10 08:48 AM, H.J. wrote:

The linker has to honor, and propagate the most restrictive visibility.
As the compiler may have "optimized" the code because of a restrictive
visibility, any less-restrictive promotion of that visibility could
compromise the compiled code.

--

Rod.

Everybody to Everest!

April 2010,  I'll climb to  Mt. Everest Base Camp  as a fund raiser for
The Challenged Athletes Foundation - www.everybodytoeverest.com.  Visit
www.everestchallenge.kintera.org/rie to show your support.  Thanks!


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
amodra  
View profile  
 More options Jan 15 2010, 8:16 pm
From: amodra <amo...@gmail.com>
Date: Fri, 15 Jan 2010 17:16:00 -0800 (PST)
Subject: Re: Should linker merge symbol visibility for weak symbol
I've been thinking a little more about this since making my comment
regarding weak symbols in http://sourceware.org/bugzilla/show_bug.cgi?id=11175#c2
(late at night and I hadn't read the visibility section of the abi
properly..)

If you accept that visibility on a reference is useful then clearly
the linker must merge visibility on all references with visibility on
the defining symbol.  It's not immediately clear that visibility on a
weak defining symbol must also be merged, but I think that follows
too.

Consider:  a) If a compiler sees a declaration with visibility
attributes it may emit code using that declaration before seeing a
later definition.  This means that definitions in an object file need
to be treated exactly the same as references regarding merging of
visibility.  Treating them differently would require that the
assembler emit two symbols with the same name, one for references and
one for definitions.  I suppose that would be possible, but isn't the
way current assemblers work.
b) If it is legal for the compiler to merge a declaration with a
visibility attribute with a later declaration with a weak attribute,
then weak and strong references must also be treated the same.

(a) and (b) combined lead to the requirement that visibility should be
merged from a weak definition to a strong definition.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
End of messages
« Back to Discussions « Newer topic     Older topic »