From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E67A63858405; Thu, 28 Oct 2021 19:41:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E67A63858405 From: "simon.marchi at polymtl dot ca" 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:41:19 +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: simon.marchi at polymtl dot ca 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: cc 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:41:21 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28018 Simon Marchi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simon.marchi at polymtl do= t ca --- Comment #11 from Simon Marchi --- (In reply to Kevin Adler from comment #10) > 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_symtab through the legacy_psymtab implementation. This then ca= lls > expand_psymtab, which ends up invoking xcoff_expand_psymtab. This then ca= lls > 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 typ= es > defined in other psymtabs it will blow up. >=20 > I modified the code to add dependencies on the prior psymtabs created for > the 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 sure if this is what the dependencies are supposed to be fo= re, > but it let me do some testing. This still doesn't work because at the sta= rt > 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. :( >=20 > Seems like the stabs/xcoff code would need a large rewrite in order to ma= ke > this all work correctly since type_vector is a global variable and not > associated with a source file/psymtab/etc. I don't understand everything here, but it sounds like you need the type ve= ctor of a previously built symtab to be accessible while reading a second symtab that depends on the first one? 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 somethi= ng like that. When symtab 2 depends on a type in symtab 1, then you could loo= kup symtab 1's type vector in that per-compunit_symtab data. Or maybe I comple= tely misunderstand the problem. > And if the comments are true > about 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 with 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. I don't know about that. --=20 You are receiving this mail because: You are on the CC list for the bug.=