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 13/8/5 äå10:24, Mike Stump wrote:
> 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.

Yes, that's what I meant. e.g. instead of using (const (unspec...)), new
RTL operators for specifying the common forms of relocations (including
those used PIC) should be defined; this will involve changing lots of
backends, so should be aimed in the long term.

Chung-Lin





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