From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8C65D385843C; Thu, 28 Oct 2021 19:10:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8C65D385843C 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 19:10:24 +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 19:10:24 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28018 --- Comment #10 from Kevin Adler --- So it looks like GDB locates the specific psymtab that contains the symbol being looked up and calls read_symtab() on it. This invokes xcoff_read_symt= ab through the legacy_psymtab implementation. This then calls expand_psymtab, which ends up invoking xcoff_expand_psymtab. This then calls expand_dependencies (but there are never dependencies, based on my last comment) and finally calls read_xcoff_symtab on the psymtab. So yeah, only = the psymtab containing the symbol will be loaded and if it depends on types def= ined in other psymtabs it will blow up. I modified the code to add dependencies on the prior psymtabs created for t= he same file (only works if the csects are adjacent/contiguous, which comments seem to indicate may not always be the case, but it's works for my testing). The first csect for a file would have no dependencies, then the second would depend on the first, the third depend on the second, and so on... I'm not s= ure if this is what the dependencies are supposed to be fore, but it let me do = some testing. This still doesn't work because at the start of read_xcoff_symtab (called for each dependency), start_stabs is called which sets type_vector = to NULL so all the types defined by the previous csect for the file are lost. = :( Seems like the stabs/xcoff code would need a large rewrite in order to make this all work correctly since type_vector is a global variable and not associated with a source file/psymtab/etc. And if the comments are true abo= ut csects for the same file being fragmented, it makes it even more complicated since you'd basically need a way to look up all the psymtabs associated wit= h a given filename. I do see that the psymtabs are all given the same name (the filename), though I'm not sure how much them having the same name actually helps. --=20 You are receiving this mail because: You are on the CC list for the bug.=