From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 67CA73857427; Mon, 25 Oct 2021 18:05:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67CA73857427 From: "kadler at us dot ibm.com" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type Date: Mon, 25 Oct 2021 18:05:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints X-Bugzilla-Version: 10.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kadler at us dot ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:05:39 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28018 --- Comment #9 from Kevin Adler --- What I've found so far while debugging against emacs 27.2 on AIX, which bui= lds with -g3: emacs.c has many include files, one of which is lisp.h which defines struct Lisp_Subr: Lisp_Subr:T714=3Ds48header:691,0,64;function:715=3Du8a0:716=3D*717=3Df671,0= ,64;a1:718=3D*719=3Df671,0,64;a2:720=3D*721=3Df671,0,64; a3:722=3D*723=3Df671,0,64;a4:724=3D*725=3Df671,0,64;a5:726=3D*727=3Df671,0,= 64;a6:728=3D*729=3Df671,0,64;a7:730=3D*731=3Df671,0,64;a8:732=3D*733=3Df671= ,0,64;aUNEVALLED:718,0,64;aMANY:734=3D*735=3Df671,0,64;;,64,64;min_ args:-3,128,16;max_args:-3,144,16;symbol_name:736=3D*737=3Dk-2,192,64;intsp= ec:736,256,64;doc:659,320,64;; This struct contains the field symbol_name, which is a const char* and so t= ype 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=3Dar114;0;00000000000000000000014;1354=3Dk736 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 CSE= CTs, 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 assertio= n 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 functio= n. >>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 i= t'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. --=20 You are receiving this mail because: You are on the CC list for the bug.=