This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR32219, weak hidden reference segfault [PING^2]


On Aug 5, 2013, at 7:15 AM, Chung-Lin Tang <cltang@codesourcery.com> wrote:
> On 13/8/5 10:06 PM, Mike Stump wrote:
>> On Aug 4, 2013, at 8:14 AM, Chung-Lin Tang <cltang@codesourcery.com> wrote:
>>> On 13/7/15 1:43 AM, Diego Novillo wrote:
>>>> Could you please repost the patch with its description?  This thread
>>>> is sufficiently old and noisy that I'm not even sure what the patch
>>>> does nor why.
>>> 
>>> Taking the same example in my first post:
>>> 
>>> Under -fPIC, the code in rtlanal.c:nonzero_address_p() does not properly
>>> recognize the "PIC-reg + <constant>" form of load as a weak symbol; it
>>> returns 'true' immediately after seeing the pic-reg indexing, and does
>>> not test the wrapped symbol for DECL_WEAK.
>> 
>> So, I can't help but think that others would say that looking into an unspec is by nature, the wrong way to do it, unless that code is in the port.
>> 
>> I think the followup from Bernhard points to a better solution, though the wording in the comment was objectionable.  Merely say that the symbol, if weak and not defined, is then not local.
> 
> When I last tested that patch which moves the DECL_WEAK check, the
> testcases for C++ TLS wrappers fail. I don't remember the fine details,
> but effectively it filters out the TLS wrappers from being treated
> locally, causing them to be called through @PLT, and regressing on some
> tests specifically checking for that…

Hum…  I wonder if there is a TLS predicate one can mix in to the check that is appropriate.

> The UNSPEC interpretation here is fairly restricted, FWIW. Earlier talk
> on this thread also mentioned that maybe specific RTL constructs for
> reasoning about PIC addresses should be introduced, rather than common
> idiomatic pattern, though that may be a long shot for now.

specifying the unspecified, make is specified, and calling it unspec, would seem to be wrong.

The right approach, long term, is to have address forms all specified and documented and a port merely can use the forms they are interested in.  pic is one of those things that should be bumped up, unspec is kinda silly.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]