From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CC3753987C1B; Fri, 30 Oct 2020 19:03:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC3753987C1B From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug symtab/26813] DW_FORM_rnglistx and DW_FORM_loclistx not fully supported Date: Fri, 30 Oct 2020 19:03:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simark at simark dot ca X-Bugzilla-Status: NEW 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: Fri, 30 Oct 2020 19:03:14 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26813 --- Comment #6 from Simon Marchi --- I'm focusing on rnglists at the moment, but it all probably applies to locl= ists too. I did the same changes as Zoran to make GDB properly handle the rngli= stx form, then hit some more important issues. First, read_rnglist_index returns a CORE_ADDR: that's wrong, because a CORE_ADDR is meant to represent an address in the program. This function returns an offset in the .debug_rnglists section, the beginning of the range list. It should probably be sect_offset. The .debug_rnglists section in the executable I uploaded looks like this: [0x00, 0x0B]: header for CU 1 [0x0C, 0x0F]: list of offsets for CU 1 (1 element) [0x10, 0x78]: range lists data for CU 1 [0x79, 0x84]: header for CU 2 [0x85, 0xB4]: list of offsets for CU 2 (12 elements) [0xB5, 0xBD7]: range lists data for CU 2 The DW_AT_rnglists_base for CU 2 points to 0x85, that is the beginning of t= he list of offsets for that CU. That's just past the header. The DW_AT_ranges value for CU 2 has value 0xb (11). When read_rnglist_inde= x is called for that index, it reads the header at the beginning of the .debug_rnglists section. That's wrong, because the header at the beginning= of the section is the header for CU 1, and we are reading a range list for CU = 2.=20 If we wanted to read a header, it should be the header at 0x79. But since = the link from CU 2 to the .debug_rnglists is DW_AT_rnglists_base, and it points after its header, I don't think we are expected to read the header to do the index -> range list conversion. Since the header is not of constant size, = we can't really just read it by going back from the location pointed by DW_AT_rnglists_base. We currently use the header to validate that the index is valid, so unfortunately I think it means we won't be able to do that. At least, not unless we do a first pass to slurp the entire .debug_rnglists section to kn= ow where the various contributions are and how many offsets they have. --=20 You are receiving this mail because: You are on the CC list for the bug.=