This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, David Edelsohn <dje dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 18 Nov 2014 13:04:37 +0100
- Subject: Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnykwBGi5YT-E8b7k_WHYTee7_XZ5zuDQhwtd1fg7giu-eg at mail dot gmail dot com> <546A414E dot 6040905 at redhat dot com> <CAMbmDYYRY8NN=NhY_P8SO4p-vAwYpgeWPVSNCt7YZxY8VHF9SQ at mail dot gmail dot com> <546AB56C dot 3000902 at redhat dot com> <CAMbmDYb2nJt40EoyNRLuAwotmO=pwE5i-u+SNKhE+jJNKRvEHQ at mail dot gmail dot com>
On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2014-11-18 5:56 GMT+03:00 Jeff Law <law@redhat.com>:
>> On 11/17/14 13:43, Ilya Enkovich wrote:
>>
>>>
>>> I don't fully understand how this problem appears. Is it fully AIX
>>> specific and doesn't affect any other target? May we put all _CHKP
>>> codes to the end of enum and ignore them by AIX? Limiting number of
>>> codes in enum due to restrictions of specific debug info format seems
>>> weird. If something cannot be encoded for debug info then it should
>>> be ignored. I really hoped that creation of functions by demand would
>>> allow to avoid such kind of problems :(
>>>
>>> I'll try to make a patch reducing amound of builtin codes to a
>>> required minimum in case it appears to be the best option we have.
>>
>> It's a problem with the AIX native tools. Presumably they don't like really
>> long lines -- it was a relatively common issue in the past with vendor
>> tools.
>>
>> I think we should proceed on two fronts. First if David could investigate
>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to
>> resolve the issue. Second if you could look at now duplicating every
>> builtin in the enumeration since it's a combination of the number of enums
>> and the length of the debug strings to represent them that's causing AIX
>> heartburn.
>>
>>
>>
>> jeff
>
> I see. I can reduce the number of _CHKP builtin codes. Experimental
> patch shows resulting END_BUILTINS = 1242. But we should expect
> similar problem for i386 target builds hosted on AIX (here
> http://toolchain.lug-owl.de/buildbot/ I see such build is tested).
> Current IX86_BUILTIN_MAX is 2467 which is greater than current
> END_BUILTINS.
I think it's better to fix dbxout.c to do something sensible with
too long lines for enum types. It should be easy to cook up a
testcase that is not GCC.
enum { entry1, entry2, entry3.... };
not sure how exactly the issue breaks AIX bootstrap though. I suppose
the assembler complains?
Richard.
> Ilya
- References:
- Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls
- Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls
- Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls
- Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls
- Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls