mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2026-08-27 00:26:02 -04:00
ea4d6431ac
A later commit in this series, that improves GDB's ability to debug optimised code, wants to use the line table information in order to "fix" inline blocks with a truncated address range. For the reasoning behind wanting to do that, please read ahead in the series. Assuming that we accept for now the need to use the line table information to adjust the block ranges, then why is this commit needed? GDB splits the line table data info different symtabs, adding end of sequence markers as we move between symtabs. This seems to work fine for GDB, but causes a problem for me in this case. What I will want to do is this: scan the line table and spot line table entries that corresponds to the end addresses of an inline block's address range. If the block meets certain requirements, then the end address of the block is adjusted to be that of the next line table entry. The way that GDB currently splits the line table entries between symtabs makes this harder. I will have the set of blocks end addresses which I know might be fixable, but to find the line table entry corresponding to that address requires searching through all the symtabs. Having found the entry for the end address, I then need to find the next line table entry. For some blocks this is easy, it's the next entry in the same symtab. But for other blocks the next entry might be in a different symtab, which requires yet another full search. I did try implementing this approach, but the number of full symtab searches is significant, and it had a significant impact on GDB's debug parsing performance. The impact was such that an operation that currently takes ~7seconds would take ~3minutes or more. Now I could possibly improve that 3 minutes figure by optimising the code some, but I think that would add unnecessary complexity. By deferring building the line table until after we have parsed the DIEs it becomes simple to spot when a line table entry corresponds to a block end address, and finding the next entry is always trivial, as, at this point, the next entry is just the next entry which we will process. With this approach I see no noticable impact on DWARF parsing performance. This patch is just the refactoring. There's no finding block end addresses and "fixing" being done here. This just sets things up for the later commits. The existing code has a single function handle_DW_AT_stmt_list which loads the line table header and then calls dwarf_decode_lines to decode the line table itself, splitting the line table entries between symtabs. After this commit handle_DW_AT_stmt_list is renamed to decode_line_header_for_cu, this loads the line table header and creates the symtabs based off the line table, but doesn't process the line table. The dwarf_decode_lines function is no longer called at this point. In read_file_scope is where dwarf_decode_lines is now called. This relies on the line table having been loaded earlier, and processes the line table entries, splitting them between symtabs. There should be no user visible changes after this commit.
30 lines
1.1 KiB
C
30 lines
1.1 KiB
C
/* DWARF 2 debugging format support for GDB.
|
|
|
|
Copyright (C) 1994-2026 Free Software Foundation, Inc.
|
|
|
|
This file is part of GDB.
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
#ifndef GDB_DWARF2_LINE_PROGRAM_H
|
|
#define GDB_DWARF2_LINE_PROGRAM_H
|
|
|
|
/* Decode the Line Number Program (LNP) for the line_header structure in
|
|
CU.
|
|
|
|
LOWPC is the lowest address in CU (or 0 if not known). */
|
|
|
|
extern void dwarf_decode_lines (struct dwarf2_cu *cu, unrelocated_addr lowpc);
|
|
|
|
#endif /* GDB_DWARF2_LINE_PROGRAM_H */
|