From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gnu-gabi-return-26-listarch-gnu-gabi=sourceware.org@sourceware.org>
Received: (qmail 124905 invoked by alias); 23 Feb 2016 17:01:31 -0000
Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:gnu-gabi@sourceware.org>
List-Help: <mailto:gnu-gabi-help@sourceware.org>
List-Subscribe: <mailto:gnu-gabi-subscribe@sourceware.org>
Sender: gnu-gabi-owner@sourceware.org
Received: (qmail 124884 invoked by uid 89); 23 Feb 2016 17:01:30 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: 
X-HELO: mx2.suse.de
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Date: Fri, 01 Jan 2016 00:00:00 -0000
From: Michael Matz <matz@suse.de>
To: "H.J. Lu" <hjl.tools@gmail.com>
cc: Alan Modra <amodra@gmail.com>, gnu-gabi@sourceware.org
Subject: Re: Specify how undefined weak symbol should be resolved in
 executable
In-Reply-To: <CAMe9rOrFK5+AQJ1RepMD_R3Kw+s5Yg3k8C-PEmMTt1MtC3tKng@mail.gmail.com>
Message-ID: <alpine.LSU.2.20.1602231756490.20277@wotan.suse.de>
References: <CAMe9rOqQ-RUhBo3NATttc1VEGhtx4D0Z9aRWfw5APfDVuBPqWQ@mail.gmail.com> <CAMe9rOoJkeBS1_=DaEUY8Ts+=b7A=83_0wgVfCa3g+dd3me4wg@mail.gmail.com> <alpine.LSU.2.20.1602221909240.20277@wotan.suse.de> <CAMe9rOrP0fxgT9tuZaNFdGJFNGAghO8dupcyy-w-nm6E3eZzkA@mail.gmail.com>
 <alpine.LSU.2.20.1602221914130.20277@wotan.suse.de> <CAMe9rOoqOvXXOjLKnyg0OPpPE4pEvN4kO6+e7nWz7Ng9LTBwSg@mail.gmail.com> <CAMe9rOq=aMiTZ_nwS9aO9ba5bj_ak4gpk9D+JSfwged70VM3mg@mail.gmail.com> <20160223044029.GE10657@bubble.grove.modra.org>
 <CAMe9rOokycUczJ-F8rafSoTygz0emiCUHz3FwVObCf=HPun=ew@mail.gmail.com> <alpine.LSU.2.20.1602231748430.20277@wotan.suse.de> <CAMe9rOrFK5+AQJ1RepMD_R3Kw+s5Yg3k8C-PEmMTt1MtC3tKng@mail.gmail.com>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-SW-Source: 2016-q1/txt/msg00024.txt.bz2

Hi,

On Tue, 23 Feb 2016, H.J. Lu wrote:

> >> Not only we need to change defined weak symbol behavior, we also need 
> >> to change undefined non-weak symbol behavior when taking its address.
> >
> > Why?  An undefined non-weak symbol reference leads to a linker error, 
> > done.  Why change that?
> 
> Make it "external non-weak symbol", which is a symbol defined in a 
> shared object.

What would you like to change in behaviour for them (and why must it be 
done at the same time as changing something for weak symbols)?  A 
reference to the address of such a function symbol from an executable 
resolves to the plt slot currently (which in turn is exported, so that 
address references from other modules resolve to the same).  A reference 
to a non-function symbol is loaded from the got.  In all cases must this 
symbol be defined somewhere (otherwise linker error), so I don't see what 
we need to change, nor why that would force DT_TEXTREL (or the compiler to 
emit PIC like code).


Ciao,
Michael.