[Bug bootstrap/64256] New: [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[Bug bootstrap/64256] New: [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

            Bug ID: 64256
           Summary: [5.0 Regression] Pointer Bounds Checker builtins enum
                    overflows stabstring length
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dje at gcc dot gnu.org

The implementation of pointer bounds checking added an extra version of all
builtins with _CHKP appended, even when -fcheck-pointer-bounds is not enabled.

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 first _CHKP builtin is 1156
END_CHKP_BUILTINS is 2381
END_BUILTINS is 2388

creating a stabstring for the enum over the 64K limit.

This fails when building stage 1 GCC.  All currently deployed GCC compilers
will fail to bootstrap GCC trunk.  Note that AIX VAC++ cannot bootstrap the C++
code in current GCC.

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-10
                 CC|                            |ienkovich at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org
               Host|                            |powerpc-ibm-aix*
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you create a small non-gcc testcase that shows the dbxout.c deficiency
please?

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So are we talking about something like:
#define A(n) EEEEEEEEEE##n,
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) \
A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) \
B(n##5) B(n##6) B(n##7) B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) \
C(n##5) C(n##6) C(n##7) C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) \
D(n##5) D(n##6) D(n##7) D(n##8) D(n##9)
#define F(n) E(n##0) E(n##1) E(n##2) E(n##3) E(n##4) \
E(n##5) E(n##6) E(n##7) E(n##8) E(n##9)
enum E
{
  F(1)
  EEEEEEEEEElast
};
enum E
foo (enum E x)
{
  return x;
}

-gstabs+ ? One .stabs line in there is 2288953 bytes long.  Looking around,
this is a well known problem for 13 years at least, just nothing has been done
about it: PR2714 .

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If I manually #undef DBX_CONTIN_LENGTH in dbxout.c before the default in there,
I get:
        .stabs 
"E:T(0,21)=eEEEEEEEEEE100000:0,EEEEEEEEEE100001:1,EEEEEEEEEE100002:2,EEEEEEEEEE100003:3,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100004:4,EEEEEEEEEE100005:5,EEEEEEEEEE100006:6,EEEEEEEEEE100007:7,EEEEEEEEEE100008:8,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100009:9,EEEEEEEEEE100010:10,EEEEEEEEEE100011:11,EEEEEEEEEE100012:12,EEEEEEEEEE100013:13,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100014:14,EEEEEEEEEE100015:15,EEEEEEEEEE100016:16,EEEEEEEEEE100017:17,EEEEEEEEEE100018:18,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100019:19,EEEEEEEEEE100020:20,EEEEEEEEEE100021:21,EEEEEEEEEE100022:22,EEEEEEEEEE100023:23,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100024:24,EEEEEEEEEE100025:25,EEEEEEEEEE100026:26,EEEEEEEEEE100027:27,EEEEEEEEEE100028:28,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100029:29,EEEEEEEEEE100030:30,EEEEEEEEEE100031:31,EEEEEEEEEE100032:32,EEEEEEEEEE100033:33,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100034:34,EEEEEEEEEE100035:35,EEEEEEEEEE100036:36,EEEEEEEEEE100037:37,EEEEEEEEEE100038:38,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100039:39,EEEEEEEEEE100040:40,EEEEEEEEEE100041:41,EEEEEEEEEE100042:42,EEEEEEEEEE100043:43,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100044:44,EEEEEEEEEE100045:45,EEEEEEEEEE100046:46,EEEEEEEEEE100047:47,EEEEEEEEEE100048:48,\\",128,0,0,0
        .stabs 
"EEEEEEEEEE100049:49,EEEEEEEEEE100050:50,EEEEEEEEEE100051:51,EEEEEEEEEE100052:52,EEEEEEEEEE100053:53,\\",128,0,0,0
...
which looks good to me.
So, to me this looks like misconfiguration of the AIX target setting, if it
can't handle string lengths larget than say 32KB or 64KB, it should make
sure DBX_CONTIN_LENGTH is not defined to 0 (infinite), but say 32000 or 65000.
Whether it should use DBX_CONTIN_CHAR '?' or '\\' is something you should test,
'\\' is the default, '?' is mentioned as AIX continuation character in the
mentioned PR,
and is used e.g. on sparc*-netbsd/freebsd.
Try gdb and whatever other debugger is commonly used on your target.
All I can say is that dbxout.c seems to have all the needed support.

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[zoltan at hidvegi dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

Zoltan Hidvegi <zoltan at hidvegi dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zoltan at hidvegi dot com

--- Comment #5 from Zoltan Hidvegi <zoltan at hidvegi dot com> ---
I've also encountered this bug in a user source code, note on AIX for 32-bit
XCOFF32 objects, the stabstring length is limited to 64k, because length is
stored in a 2-byte field. Compiling with -maix64 works for these sources:
http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/ssw_aix_53/com.ibm.aix.files/doc/aixfiles/XCOFF.htm#x83wh24fshar

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[zoltan at hidvegi dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #6 from Zoltan Hidvegi <zoltan at hidvegi dot com> ---
Created attachment 34672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34672&action=edit
Patch to limit dbx stabstring length to 32000

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[zoltan at hidvegi dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #7 from Zoltan Hidvegi <zoltan at hidvegi dot com> ---
With the above trivial change I've been able to build code with long
stabstrings on AIX 6.1. I was using the gcc-4.8 branch since that's what we are
using here. If you fix this, could you please also apply it to the gcc-4.8 and
gcc-4.9 branches as well?

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #8 from David Edelsohn <dje at gcc dot gnu.org> ---
Thanks for the patch, Zoltan, but the patch is not the challenge.  It is not
difficult to instruct GCC to generate stabs with continuation.  The question
always has been if the debuggers on AIX can understand stabs with
continuations.

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[zoltan at hidvegi dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #9 from Zoltan Hidvegi <zoltan at hidvegi dot com> ---
xlC generates stubs with continuation, and it seems to cut them at 16k both for
32-bit and 64-bit objects, so maybe gcc could do the same. gdb-7.7.1 seems to
segfault on stubs longer than 32k for 32-bit executables, although long stubs
work with 64-bit executables. My brief testing showed that it indeed handles
continuations as long as all parts are under 32k. There is also totalview, I
haven't tried that. Other debuggers on AIX often have trouble dealing with the
debug info of g++.

But regardless of debugger support, there is really no alternative to using
continuation for XCOFF32. And as others have said this bug has been in gcc for
a long time, and has been brought up by several bugreports, e.g. also in
PR46072

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> ---
Stabstring continuations originally seem to have been disabled for AIX XCOFF
because the AIX assembler did not support them correctly.  IBM's proprietary
compiler, VAC/XLC, directly generates object files and does not use the AIX
assembler.  XLC produces assembly language files by invoking a disassembler on
the object file.

The AIX XCOFF documentation and stabstring grammar defined continuations, XLC
produced them, the disassembler displayed them, AIX ld supported them, AIX DBX
supported them, but AIX Assembler did not.  No one manually wrote assembly
language files with long enough stabstrings (or any stabstrings) to trip over
the bug.

GCC is the biggest user of the AIX assembler.

At some point the AIX assembler was fixed and now properly supports stabstring
continuations.  As Zoltan mentioned, XLC seems to limit stabstrings to 16K.  XL
disassembler also uses '?' as the continuation character.  GDB accepts '?' as
an alternate continuation character, in addition to '\\'.  On AIX, it is safer
to produce code similar to XLC because the rest of the AIX tools consume that
and problems can be reproduced with native tools, ensuring fixes.

I will test the following patch

Index: xcoffout.h
===================================================================
--- xcoffout.h  (revision 220457)
+++ xcoffout.h  (working copy)
@@ -161,9 +161,12 @@
 /* Do not emit any marker for XCOFF until assembler allows XFT_CV.  */
 #define NO_DBX_GCC_MARKER

-/* Do not break .stabs pseudos into continuations.  */
-#define DBX_CONTIN_LENGTH 0
+/* XCOFF32 maximum length is 64K; XLC limits to 16K.  */
+#define DBX_CONTIN_LENGTH 16384

+/* XLC uses '?' as continuation character.  */
+#define DBX_CONTIN_CHAR '?'
+
 /* Don't try to use the `x' type-cross-reference character in DBX data.
    Also has the consequence of putting each struct, union or enum
    into a separate .stabs, containing only cross-refs to the others.  */

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[zoltan at hidvegi dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #11 from Zoltan Hidvegi <zoltan at hidvegi dot com> ---
Do you have more info regarding the AIX assembler bug you are referring to?
PR46072 was about a different assembler bug, it's just someone in that report
have also encountered the stabstring length issue. I was under the impression,
that the assembler does not interpret the stab continuation at all, it just
puts stabstring entries as is into the xcoff object file, and the continuation
is needed because of the 64k limit imposed by the XCOFF32 object file format,
and therefore multiple stab entries would be present in the .o file for long
stabs and the debugger is supposed to handle that as if it was a single long
stabstring.

[Bug bootstrap/64256] [5.0 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

--- Comment #12 from David Edelsohn <dje at gcc dot gnu.org> ---
Author: dje
Date: Sat Feb  7 02:34:38 2015
New Revision: 220501

URL: https://gcc.gnu.org/viewcvs?rev=220501&root=gcc&view=rev
Log:
        PR debug/2714
        PR bootstrap/64256
        * xcoffout.h (DBX_CONTIN_LENGTH): Define as 16384.
        (DBX_CONTIN_CHAR): Define.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/xcoffout.h

[Bug bootstrap/64256] [5 Regression] Pointer Bounds Checker builtins enum overflows stabstring length

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
            Summary|[5.0 Regression] Pointer    |[5 Regression] Pointer
                   |Bounds Checker builtins     |Bounds Checker builtins
                   |enum overflows stabstring   |enum overflows stabstring
                   |length                      |length

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.