From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 435623858437; Thu, 28 Oct 2021 21:16:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 435623858437 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: Thu, 28 Oct 2021 21:16:29 +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: Thu, 28 Oct 2021 21:16:29 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28018 --- Comment #12 from Kevin Adler --- > DWARF keeps some data associated to each compunit_symtab on the side, in = the > dwarf2_per_objfile::m_symtabs field. It sounds like you would need somet= hing=20 > like that. When symtab 2 depends on a type in symtab 1, then you could l= ookup=20 > symtab 1's type vector in that per-compunit_symtab data. Or maybe I comp= letely > misunderstand the problem. Yeah, I think something like this will be necessary. I actually found a pat= ches the AIX team has in their build of GDB 8.1 that does something like this. T= hat was to address issues when using --function-sections/-qfuncsect, which makes this problem worse by putting every function in to its own csect. BTW, I actually confused myself initially. While we _are_ failing to look up the element type of the array, the assertion is not on that type, but on the type used to index the array. I didn't even realize that could or needed be specified. :) One hack around the assertion problem would be to check if we got an undefined type when looking up the index type and in that case overr= ide the type using the builtin type for unsigned long. Of course, that wouldn't= fix the larger issue and so the element type of the array would still be undefi= ned. --=20 You are receiving this mail because: You are on the CC list for the bug.=