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

Ilya Enkovich enkovich.gnu@gmail.com
Mon Nov 17 21:13:00 GMT 2014


2014-11-17 21:41 GMT+03:00 Jeff Law <law@redhat.com>:
> On 11/17/14 11:22, David Edelsohn wrote:
>>
>> However, the patch causes another problem that breaks bootstrap on
>> AIX.  All of the builtins are emitted as an enum in debug information
>> and the CHKP enums now cause an overflow in the debug data on AIX.
>> AIX continues to use stabstrings debugging and does not permit stabs
>> continuation lines.
>>
>> This also is failing while building stage1 GCC -- all currently
>> deployed GCC compilers will fail when building GCC trunk.  No change
>> to the debugging information produced by GCC trunk will fix this.
>>
>> Over half of the enum list now contains CHKP.
>>
>> the first _CHKP builtin is 1156
>> END_CHKP_BUILTINS is 2381
>> END_BUILTINS is 2388
>>
>> All of the normal builtins now appear to be duplicated with CHKP versions.
>>
>> This is a huge amount of bloat in the common parts of GCC for a
>> feature that only is available on Intel.  Can you please disable the
>> feature that creates duplicate CHKP versions of builtins on non-Intel
>> architectures or at least on AIX (_AIX macro defined)?
>
> Note all the initialization and such for these builtins is done on-demand.
> The only bloat is in the enum list, which is obviously causing AIX problems.
>
> It's unfortunately AIX continues to use stabs rather than an embedded dwarf
> format.  Sigh.
>
>
>>
>> Thanks for your earlier fixes, but can we please adjust the
>> implementation so that it does not break other platforms?
>
> FWIW, that implementation was largely done to keep things clean throughout
> the gimple phases and keep the maintenance burden down to something
> reasonable.
>
> Ilya, can we create a tag on the builtins we want to have a _chkp duplicate,
> then build a map from the original builtin enum to the _chkp variant so that
> we don't have to duplicate the entire table, but so that we still get the
> cleaner design of the version that was approved?
>
> jeff

Taking into account current number of builtins actually instrumented,
it can be done even manually :)  I like current approach because it
allows us to switch to 'instrument everything' mode easily.  Selective
enum codes generation would mean we can never mark all of them as
instrumentable.

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.

Thanks,
Ilya



More information about the Gcc-patches mailing list