On Mon, Nov 17, 2014 at 3:43 PM, Ilya Enkovich <enkovich....@gmail.com> wrote:
> 2014-11-17 21:41 GMT+03:00 Jeff Law <l...@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.
I am not a stabstring expert, but the output that I am seeing in
almost every assembler file and the output that is overflowing the
file is:
.stabx
"built_in_function:t1527=eBUILT_IN_NONE:0,BUILT_IN_ACOS:1,BUILT_IN_ACOSF:2,BUILT_IN_ACOSH:3,BUILT_IN_ACOSHF:4,BUILT_IN_ACOSHL:5,BUILT_IN_ACOSL:6,BUILT_IN_ALIGNED_ALLOC:7,BUILT_IN_ASIN:8,BUILT_IN_ASINF:9,BUILT_IN_ASINH:10,BUILT_IN_ASINHF:11,BUILT_IN_ASINHL:12,BUILT_IN_ASINL:13,BUILT_IN_ATAN:14,BUILT_IN_ATAN2:15,BUILT_IN_ATAN2F:16,BUILT_IN_ATAN2L:17,BUILT_IN_ATANF:18,BUILT_IN_ATANH:19,BUILT_IN_ATANHF:20,BUILT_IN_ATANHL:21,BUILT_IN_ATANL:22,BUILT_IN_CBRT:23,BUILT_IN_CBRTF:24,BUILT_IN_CBRTL:25,BUILT_IN_CEIL:26,BUILT_IN_CEILF:27,BUILT_IN_CEILL:28,BUILT_IN_COPYSIGN:29,BUILT_IN_COPYSIGNF:30,BUILT_IN_COPYSIGNL:31,BUILT_IN_COS:32,BUILT_IN_COSF:33,BUILT_IN_COSH:34,BUILT_IN_COSHF:35,BUILT_IN_COSHL:36,BUILT_IN_COSL:37,BUILT_IN_DREM:38,BUILT_IN_DREMF:39,BUILT_IN_DREML:40,BUILT_IN_ERF:41,BUILT_IN_ERFC:42,BUILT_IN_ERFCF:43,BUILT_IN_ERFCL:44,BUILT_IN_ERFF:45,BUILT_IN_ERFL:46,BUILT_IN_EXP:47,BUILT_IN_EXP10:48,BUILT_IN_EXP10F:49,BUILT_IN_EXP10L:50,BUILT_IN_EXP2:51,BUILT_IN_EXP2F:52,BUILT_IN_EXP2L:53,BUILT_IN_EXPF:54,BUILT_IN_EXPL:55,BUILT_IN_EXPM1:56,BUILT_IN_EXPM1F:57,BUILT_IN_EXPM1L:58,BUILT_IN_FABS:59,BUILT_IN_FABSF:60,BUILT_IN_FABSL:61,BUILT_IN_FABSD32:62,BUILT_IN_FABSD64:63,
...
BUILT_IN_CHKP_INTERSECT:1156,BUILT_IN_CHKP_SIZEOF:1157,BUILT_IN_CHKP_NARROW:1158,B
UILT_IN_CHKP_BNDCL:1159,BUILT_IN_CHKP_BNDCU:1160,BUILT_IN_CHKP_BNDSTX:1161,BUILT
_IN_CHKP_BNDLDX:1162,BUILT_IN_CHKP_BNDRET:1163,BUILT_IN_CHKP_BNDMK:1164,BUILT_IN
_CHKP_EXTRACT_LOWER:1165,BUILT_IN_CHKP_EXTRACT_UPPER:1166,BUILT_IN_CHKP_SET_PTR_
BOUNDS:1167,BUILT_IN_CHKP_INIT_PTR_BOUNDS:1168,BUILT_IN_CHKP_NULL_PTR_BOUNDS:116
9,BUILT_IN_CHKP_COPY_PTR_BOUNDS:1170,BUILT_IN_CHKP_NARROW_PTR_BOUNDS:1171,BUILT_
IN_CHKP_STORE_PTR_BOUNDS:1172,BUILT_IN_CHKP_CHECK_PTR_LBOUNDS:1173,BUILT_IN_CHKP
_CHECK_PTR_UBOUNDS:1174,BUILT_IN_CHKP_CHECK_PTR_BOUNDS:1175,BUILT_IN_CHKP_GET_PT
R_LBOUND:1176,BUILT_IN_CHKP_GET_PTR_UBOUND:1177,BUILT_IN_CHKP_MEMCPY_NOBND:1178,
BUILT_IN_CHKP_MEMCPY_NOCHK:1179,BUILT_IN_CHKP_MEMCPY_NOBND_NOCHK:1180,BUILT_IN_C
HKP_MEMMOVE_NOBND:1181,BUILT_IN_CHKP_MEMMOVE_NOCHK:1182,BUILT_IN_CHKP_MEMMOVE_NO
BND_NOCHK:1183,BUILT_IN_CHKP_MEMPCPY_NOBND:1184,BUILT_IN_CHKP_MEMPCPY_NOCHK:1185
,BUILT_IN_CHKP_MEMPCPY_NOBND_NOCHK:1186,BUILT_IN_CHKP_MEMSET_NOBND:1187,BUILT_IN
_CHKP_MEMSET_NOCHK:1188,BUILT_IN_CHKP_MEMSET_NOBND_NOCHK:1189,BEGIN_CHKP_BUILTIN
S:1190,BUILT_IN_NONE_CHKP:1191,BUILT_IN_ACOS_CHKP:1192,BUILT_IN_ACOSF_CHKP:1193,
BUILT_IN_ACOSH_CHKP:1194,BUILT_IN_ACOSHF_CHKP:1195,BUILT_IN_ACOSHL_CHKP:1196,BUI
LT_IN_ACOSL_CHKP:1197,BUILT_IN_ALIGNED_ALLOC_CHKP:1198,BUILT_IN_ASIN_CHKP:1199,B
UILT_IN_ASINF_CHKP:1200,BUILT_IN_ASINH_CHKP:1201,BUILT_IN_ASINHF_CHKP:1202,BUILT
_IN_ASINHL_CHKP:1203,BUILT_IN_ASINL_CHKP:1204,BUILT_IN_ATAN_CHKP:1205,BUILT_IN_A
TAN2_CHKP:1206,BUILT_IN_ATAN2F_CHKP:1207,BUILT_IN_ATAN2L_CHKP:1208
...
BUILT_IN_CHKP_MEMSET_NOBND_NOCHK_CHKP:2380,END_CHKP_BUILTINS:2381,BUILT_IN_COMPLEX_MUL_MIN:2382,BUILT_IN_COMPLEX_MUL_MAX:2384,BUILT_IN_COMPLEX_DIV_MIN:2385,BUILT_IN_COMPLEX_DIV_MAX:2387,END_BUILTINS:2388,;",0,140,0
See tree-core.h
/* Codes that identify the various built in functions
so that expand_call can identify them quickly. */
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM,
enum built_in_function {
#include "builtins.def"
BEGIN_CHKP_BUILTINS,
#undef DEF_BUILTIN
#define DEF_BUILTIN(ENUM, N, C, T, LT, B, F, NA, AT, IM, COND) ENUM##_CHKP,
#include "builtins.def"
END_CHKP_BUILTINS,
The header now includes builtins.def twice, including defining every
builtin a second time with _CHKP appended, even when
-fcheck-pointer-bounds is not enabled. That is what is causing the
failure on AIX.
Eventually something else will overflow the list of builtins and GCC
should not generate broken assembly debug information. Obviously no
one expected GCC to generate a type or enum larger than 64K.
Thanks, David
