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, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls


On Mon, Nov 17, 2014 at 1:41 PM, Jeff Law <law@redhat.com> wrote:
> 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.

Recent versions of AIX now have support for DWARF.  I don't know if it
has arbitrary length limits like this as well.  Adacore has an
implementation and I hope that they will contribute the patch
eventually.

The other complexity is IBM backported the feature to earlier versions
of AIX, but there is no major or minor AIX version number that
definitely has the support.  It's in service packs.  AIX support for
ELF-like visibility is the same.  This means that there is no easy way
to distribute pre-built binaries of GCC for AIX that end users easily
can know if they have the correct prerequisites.  And also means that
one may not be able to share object files and libraries across all AIX
systems at a particular version number.  Sigh^2.

>> 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?

That is a fine solution, but is it really necessary to provide this
feature on all targets, even if they don't support CHKP?  Why not nop
chkp_versioning for non-Intel targets?

Thanks, David


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