From: Tom Tromey <tom@tromey.com>
To: Tom Tromey <tom@tromey.com>
Cc: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 00/32] Rewrite the DWARF "partial" reader
Date: Mon, 22 Nov 2021 12:59:49 -0700 [thread overview]
Message-ID: <87mtlwx8p6.fsf@tromey.com> (raw)
In-Reply-To: <87a6i31woz.fsf@tromey.com> (Tom Tromey's message of "Tue, 16 Nov 2021 16:56:44 -0700")
Tom> I'll send v3 of the series once I do some more testing... I plan to
Tom> regression test with a few different approaches (dwz, probably
Tom> split DWARF too).
I think the branch is regression free in the normal case and when using
the cc-with-dwz-m board.
I also tried the fission-dwp board, and I have a single regression. I'm
inclined to ignore this one, but I figured I'd describe it first in case
anyone wants to lobby for it to be fixed.
First, the regression only affects one Ada test case, dgopt.exp, and
only when using fission-dwp. In this scenario, the executable has a
stub CU that looks like:
<0><3f>: Abbrev Number: 1 (DW_TAG_compile_unit)
[...]
<50> DW_AT_stmt_list : 0x24d
[...]
<58> DW_AT_comp_dir : (indirect string, offset: 0x0): /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.ada/dgopt
Note there is no DW_AT_name.
The corresponding .dwo file says:
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
[...]
<e> DW_AT_name : (indexed string: 0x1): /home/tromey/gdb/binutils-gdb/gdb/testsuite/gdb.ada/dgopt/x.adb
<f> DW_AT_comp_dir : (indexed string: 0x2): /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.ada/dgopt
That is, this has the correct file name in DW_AT_name. This is why the
psymtab reader works -- the psymtab reader uses the line table, but also
uses this name for file name matches.
The line table does not mention x.adb, but instead:
The File Name Table (offset 0x26a):
Entry Dir Time Size Name
1 0 0 0 x.adb.dg
That is, the file name table here holds the name of a file that's
generated by the Ada compiler when run in a special mode.
So, my inclination is to say that this is probably a compiler bug, or in
any case an obscure oddity that gdb shouldn't bother with. To my
knowledge, there aren't Ada users who also use Fission anyway.
I do think this could be fixed. It would require maybe storing a
file_and_directory in the dwarf2_per_cu_data. So if you think this is
important, I'd probably refactor to take this approach.
TBH I had expected this scenario to make a .gdb_index -- that's what
fission-dwp is supposed to do, I think, via gold -- but this didn't
happen. So possibly this is another oddity in the Ada toolchain, or
maybe the gdb test suite. I'm not certain.
Tom
next prev parent reply other threads:[~2021-11-22 20:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-04 18:08 Tom Tromey
2021-11-04 18:08 ` [PATCH v2 01/32] Introduce make_unique_xstrndup Tom Tromey
2021-11-05 19:20 ` Simon Marchi
2021-11-05 20:08 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 02/32] Split create_addrmap_from_aranges Tom Tromey
2021-11-04 18:08 ` [PATCH v2 03/32] Add dwarf2_per_cu_data::addresses_seen Tom Tromey
2021-11-04 18:08 ` [PATCH v2 04/32] Refactor dwarf2_get_pc_bounds Tom Tromey
2021-11-05 19:51 ` Simon Marchi
2021-11-24 15:53 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 05/32] Allow ada_decode not to decode operators Tom Tromey
2021-11-04 18:08 ` [PATCH v2 06/32] Let skip_one_die not skip children Tom Tromey
2021-11-04 18:08 ` [PATCH v2 07/32] Add name splitting Tom Tromey
2021-11-04 18:08 ` [PATCH v2 08/32] Add new overload of dwarf5_djb_hash Tom Tromey
2021-11-05 20:01 ` Simon Marchi
2021-11-07 17:02 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 09/32] Refactor build_type_psymtabs_reader Tom Tromey
2021-11-04 18:08 ` [PATCH v2 10/32] Add batching parameter to parallel_for_each Tom Tromey
2021-11-04 18:08 ` [PATCH v2 11/32] Return vector of results from parallel_for_each Tom Tromey
2021-11-17 20:37 ` Lancelot SIX
2021-11-18 14:41 ` Tom Tromey
2021-11-04 18:08 ` [PATCH v2 12/32] Specialize std::hash for gdb_exception Tom Tromey
2021-11-04 18:08 ` [PATCH v2 13/32] Introduce DWARF abbrev cache Tom Tromey
2021-11-04 18:08 ` [PATCH v2 14/32] Statically examine abbrev properties Tom Tromey
2021-11-04 18:08 ` [PATCH v2 15/32] Update skip_one_die for new " Tom Tromey
2021-11-04 18:08 ` [PATCH v2 16/32] Introduce the new DWARF index class Tom Tromey
2021-11-04 18:08 ` [PATCH v2 17/32] The new DWARF indexer Tom Tromey
2021-11-04 18:08 ` [PATCH v2 18/32] Implement quick_symbol_functions for cooked DWARF index Tom Tromey
2021-11-04 18:08 ` [PATCH v2 19/32] Wire in the new DWARF indexer Tom Tromey
2021-11-04 18:08 ` [PATCH v2 20/32] Introduce thread-safe handling for complaints Tom Tromey
2021-11-04 18:08 ` [PATCH v2 21/32] Pre-read DWARF section data Tom Tromey
2021-11-04 18:08 ` [PATCH v2 22/32] Parallelize DWARF indexing Tom Tromey
2021-11-04 18:08 ` [PATCH v2 23/32] "Finalize" the DWARF index in the background Tom Tromey
2021-11-04 18:08 ` [PATCH v2 24/32] Rename write_psymtabs_to_index Tom Tromey
2021-11-04 18:09 ` [PATCH v2 25/32] Change the key type in psym_index_map Tom Tromey
2021-11-04 18:09 ` [PATCH v2 26/32] Change parameters to write_address_map Tom Tromey
2021-11-04 18:09 ` [PATCH v2 27/32] Genericize addrmap handling in the DWARF index writer Tom Tromey
2021-11-04 18:09 ` [PATCH v2 28/32] Adapt .gdb_index writer to new DWARF scanner Tom Tromey
2021-11-04 18:09 ` [PATCH v2 29/32] Adapt .debug_names " Tom Tromey
2021-11-04 18:09 ` [PATCH v2 30/32] Enable the new DWARF indexer Tom Tromey
2021-11-04 18:09 ` [PATCH v2 31/32] Delete DWARF psymtab code Tom Tromey
2021-11-04 18:09 ` [PATCH v2 32/32] Remove dwarf2_per_cu_data::v Tom Tromey
2021-11-06 12:25 ` [PATCH v2 00/32] Rewrite the DWARF "partial" reader Tom de Vries
2021-11-11 12:23 ` Tom de Vries
2021-11-16 23:56 ` Tom Tromey
2021-11-17 9:22 ` Tom de Vries
2021-11-18 14:43 ` Tom Tromey
2021-11-22 19:59 ` Tom Tromey [this message]
2021-11-22 20:52 ` Tom de Vries
2021-11-22 22:11 ` Tom Tromey
2021-11-23 7:56 ` Tom de Vries
2021-11-23 17:00 ` Tom Tromey
2021-11-08 17:41 ` Simon Marchi
2021-11-10 19:56 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mtlwx8p6.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).