Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

2014-11-18 15:04 GMT+03:00 Richard Biener <richard.guenther@gmail.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.... };
>

As I understand the main problem is that fixing dbxout in trunk won't
help to build stage1 compiler.

> not sure how exactly the issue breaks AIX bootstrap though.  I suppose
> the assembler complains?

It is linker how complaints. Here is a build log example:
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=3073584

Ilya

>
> Richard.
>
>> Ilya