This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] PR32219, weak hidden reference segfault [PING^2]
- From: Chung-Lin Tang <cltang at codesourcery dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: Diego Novillo <dnovillo at google dot com>, Bernhard Reutner-Fischer <rep dot dot dot nop at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan_sidwell at mentor dot com>, <rdsandiford at googlemail dot com>, Richard GÃnther <rguenther at suse dot de>, Jeff Law <law at redhat dot com>
- Date: Mon, 5 Aug 2013 22:42:49 +0800
- Subject: Re: [PATCH] PR32219, weak hidden reference segfault [PING^2]
- References: <518B71DA dot 1030302 at codesourcery dot com> <878v3nt91c dot fsf at talisman dot default> <51935F65 dot 4000803 at codesourcery dot com> <87hai4a1ce dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <51A85B99 dot 1040102 at codesourcery dot com> <CAC1BbcRkA52ytKsSD3xm2GdgVhSQ+s3vfT3a=gvdCheGZ0LvhQ at mail dot gmail dot com> <51C2A8B4 dot 9020302 at codesourcery dot com> <51E26AA1 dot 7070808 at codesourcery dot com> <CAD_=9DRF6aD=5Rm=V4F3jMYuGV46YCD4LEqZfvHXGDCKvbjgrQ at mail dot gmail dot com> <51FE6FDC dot 2090500 at codesourcery dot com> <83D3619B-170E-412A-AC78-96DA20AAE671 at mrs dot kithrup dot com> <51FFB382 dot 8030902 at codesourcery dot com> <405E85EE-7402-452D-8491-241801D2465B at comcast dot net>
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