public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug mi/23042] typedef resolution traverses all CUs for MI var-create Date: Thu, 28 May 2020 11:40:05 +0000 [thread overview] Message-ID: <bug-23042-4717-5OxC1PnQfy@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-23042-4717@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=23042 --- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> --- My best guess is: if some of those shared libraries are build with gold .gdb_index, but not with -ggnu-pubnames (implied by -gsplit-dwarf), you get "[global, no info]" .gdb_index entries, also for size_t. So, if a shared lib has 100 CUs, each defining size_t, and the .gdb_index has "[global, no info]" entries for each of those, then when executing dw2_lookup_symbol for size_t with block_index GLOBAL_BLOCK: - the dw2_symtab_iter_next will return the CU for the first entry - dw2_instantiate_symtab is called for that CU - block_find_symbol is called, which fails because size_t is static, not global - the dw2_symtab_iter_next will return the CU for the next entry - and so on The workaround for PR15646 is not activated in this case because !attrs_valid, which is defined as: ... /* Only check the symbol attributes if they're present. Indices prior to version 7 don't record them, and indices >= 7 may elide them for certain symbols (gold does this). */ int attrs_valid = (dwarf2_per_objfile->per_bfd->index_table->version >= 7 && symbol_kind != GDB_INDEX_SYMBOL_KIND_NONE); ... I'm currently preparing a patch to limit the scope of the workaround to symbol_kind == GDB_INDEX_SYMBOL_KIND_TYPE, because in some cases we do want symbol lookup to find multiple version of a symbol. Extending the workaround to GDB_INDEX_SYMBOL_KIND_NONE would break that (and other things as well, I guess, given that we cannot tell global and static apart). We could try harder in dw2_lookup_symbol, by iterating twice, first using all but GDB_INDEX_SYMBOL_KIND_NONE symbols, and then the GDB_INDEX_SYMBOL_KIND_NONE ones. But that wouldn't help for this case. We could do a scan of a .gdb_index, find all untyped entries, and revert back to partial symbols for those ones. With a less fine granularity, we could do a scan of a .gdb_index, and upon finding one untyped entry, revert to partial symbols for the whole objfile. But as comment 4 shows, that would make gold --gdb-index unusable on my system, unless I modify the glibc package to build elf-init.c using -ggnu-pubnames. That fastest solution obviously would be to make sure that gold -gdb-index is always paired with -ggnu-pubnames. -- You are receiving this mail because: You are on the CC list for the bug.
prev parent reply other threads:[~2020-05-28 11:40 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-23042-4717@http.sourceware.org/bugzilla/> 2020-05-28 7:51 ` vries at gcc dot gnu.org 2020-05-28 10:43 ` vries at gcc dot gnu.org 2020-05-28 11:40 ` vries at gcc dot gnu.org [this message]
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=bug-23042-4717-5OxC1PnQfy@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /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: linkBe 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).