[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

["kadler at us dot ibm.com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #9 from Kevin Adler <kadler at us dot ibm.com> ---
What I've found so far while debugging against emacs 27.2 on AIX, which builds
with -g3:

emacs.c has many include files, one of which is lisp.h which defines struct
Lisp_Subr:


Lisp_Subr:T714=s48header:691,0,64;function:715=u8a0:716=*717=f671,0,64;a1:718=*719=f671,0,64;a2:720=*721=f671,0,64;
a3:722=*723=f671,0,64;a4:724=*725=f671,0,64;a5:726=*727=f671,0,64;a6:728=*729=f671,0,64;a7:730=*731=f671,0,64;a8:732=*733=f671,0,64;aUNEVALLED:718,0,64;aMANY:734=*735=f671,0,64;;,64,64;min_
args:-3,128,16;max_args:-3,144,16;symbol_name:736=*737=k-2,192,64;intspec:736,256,64;doc:659,320,64;;

This struct contains the field symbol_name, which is a const char* and so type
736 is defined for it (736 is a pointer type of 737, which is a constant
version of builtin RS/600 type -2, which is char)

Later in emacs.c, usage_message is declared as static char const *const
usage_message[]. The following stabstring is defined for it by GCC:

usage_message:S1353=ar114;0;00000000000000000000014;1354=k736

We have then a global static (S) type 1353 which is an array (type 114) with
range 0-12 (14 octal) and the type of the array (1354) is a constant (k)
version of 736 (ie. const char*).

So this all seems fine, but when we try to look up the index type (736) in
dbx_alloc_type, it's not found and so a new type is allocated by calling
alloc_type, initialized to TYPE_CODE_UNDEF. This type is then passed to
create_range_type, causing the assertion to fail.

The question is: why is the 736 reference type not found? It seems that in this
case, there are 3 CSECTs for emacs.c and only the one containing main is
analyzed when the failure occurs so the 736 type hasn't been allocated.

>From the tracing I've done, scan_xcoff_symtab does read through all the CSECTs,
though it seems there's maybe a bug processing the first CSECT. Even after
making some changes to call xcoff_start_psymtab for this first CSECT (which
contains 736) read_xcoff_symtab is never called for this pst. I thought
possibly they were getting read in reverse order and so the assertion is hit
before it gets to reading the pst, but no even after disabling the assertion I
can see from my trace file that the pst containing type 736 is passed to
read_xcoff_symtab at all.

There is this comment in xcoffread.c that might hint at the problem here:

              /* A program csect is seen.  We have to allocate one
             symbol table for each program csect.  Normally gdb
             prefers one symtab for each source file.  In case
             of AIX, one source file might include more than one
             [PR] csect, and they don't have to be adjacent in
             terms of the space they occupy in memory.  Thus, one
             single source file might get fragmented in the
             memory and gdb's file start and end address
             approach does not work!  GCC (and I think xlc) seem
             to put all the code in the unnamed program csect.  */

But this comment is in read_xcoff_symtab, which we're not getting to anyway.

At this point, I'm still trying to figure out how we got in to this function.
>From there I could backtrack and figure out why it's not getting called for the
other symtab containing the definition. From what I can tell, possibly the only
caller of read_symtab is psymtab_to_symtab and the only caller of
expand_psymtab is expand_dependencies.

Side note: while looking at the latter, I noticed that scan_xcoff_symtab
allocates an array of up to 30 dependent psymtabs, but dependencies_used is
only ever set to 0 so psymtabs never have any dependents. I'm not sure if it's
a bug or some vestigial code due to refactoring. The code is like this going
back to c906108, which seems to be when the file was added to the repo, but I'm
not sure how the history was imported to git if some of that earlier history
was lost.

-- 
You are receiving this mail because:
You are on the CC list for the bug.