public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/29105] new DWARF reader still slow
Date: Wed, 14 Dec 2022 10:23:37 +0000	[thread overview]
Message-ID: <bug-29105-4717-hIRUsywBf3@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-29105-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=29105

--- Comment #29 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12

commit 9f50fe0835850645bd8ea9bb1efe1fe6c48dfb12
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Wed Dec 7 15:55:25 2022 +0000

    gdb/testsuite: new test for recent dwarf reader issue

    This commit provides a test for this commit:

      commit 55fc1623f942fba10362cb199f9356d75ca5835b
      Date:   Thu Nov 3 13:49:17 2022 -0600

          Add name canonicalization for C

    Which resolves PR gdb/29105.  My reason for writing this test was a
    desire to better understand the above commit, my process was to study
    the commit until I thought I understood it, then write a test to
    expose the issue.  As the original commit didn't have a test, I
    thought it wouldn't hurt to commit this upstream.

    The problem tested for here is already described in the above commit,
    but I'll give a brief description here.  This description describes
    GDB prior to the above commit:

      - Builtin types are added to GDB using their canonical name,
        e.g. "short", not "signed short",

      - When the user does something like 'p sizeof(short)', then this is
        handled in c-exp.y, and results in a call to lookup_signed_type
        for the name "int".  The "int" here is actually being looked up as
        the type for the result of the 'sizeof' expression,

      - In lookup_signed_type GDB first adds a 'signed' and looks for that
        type, so in this case 'signed int', and, if that lookup fails, GDB
        then looks up 'int',

      - The problem is that 'signed int' is not the canonical name for a
        signed int, so no builtin type with that name will be found, GDB
        will then go to each object file in turn looking for a matching
        type,

      - When checking each object file, GDB will first check the partial
        symtab to see if the full symtab should be expanded or not.
        Remember, at this point GDB is looking for 'signed int', there
        will be no partial symbols with that name, so GDB will not expand
        anything,

      - However, GDB checks each partial symbol using multiple languages,
        not just the current language (C in this case), so, when GDB
        checks using the C++ language, the symbol name is first
        canonicalized (the code that does this can be found
        lookup_name_info::language_lookup_name).  As the canonical form of
        'signed int' is just 'int', GDB then looks for any symbols with
        the name 'int', most partial symtabs will contain such a symbol,
        so GDB ends up expanding pretty much every symtab.

    The above commit fixes this by avoiding the use of non-canonical names
    with C, now the initial builtin type lookup will succeed, and GDB
    never even considers whether to expand any additional symtabs.

    The test case creates a library that includes char, short, int, and
    long types, and a test program that links against the library.

    In the test script we start the inferior, but don't allow it to
    progress far enough that the debug information for the library has
    been fully expanded yet.

    Then we evaluate some 'sizeof(TYPE)' expressions.

    In the buggy version of GDB this would cause the debug information
    for the library to be fully expanded, while in the fixed version of
    GDB this will not be the case.

    We use 'info sources' to determine if the debug information has been
    fully expanded or not.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105

-- 
You are receiving this mail because:
You are on the CC list for the bug.

      parent reply	other threads:[~2022-12-14 10:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 19:51 [Bug symtab/29105] New: " tromey at sourceware dot org
2022-04-29 20:09 ` [Bug symtab/29105] " tromey at sourceware dot org
2022-05-13 20:56 ` tromey at sourceware dot org
2022-05-13 21:01 ` tromey at sourceware dot org
2022-05-16 18:51 ` tromey at sourceware dot org
2022-05-18 16:12 ` simon.marchi at polymtl dot ca
2022-05-20  1:54 ` simark at simark dot ca
2022-05-20 15:13 ` tromey at sourceware dot org
2022-05-20 15:36 ` simon.marchi at polymtl dot ca
2022-05-20 15:48 ` simon.marchi at polymtl dot ca
2022-05-26 13:49 ` cvs-commit at gcc dot gnu.org
2022-05-26 13:50 ` tromey at sourceware dot org
2022-07-13 16:49 ` tromey at sourceware dot org
2022-09-23 20:23 ` tromey at sourceware dot org
2022-09-23 20:44 ` tromey at sourceware dot org
2022-10-02  0:19 ` brobecker at gnat dot com
2022-10-06 20:44 ` tromey at sourceware dot org
2022-10-24 19:27 ` simon.marchi at polymtl dot ca
2022-11-01 20:42 ` tromey at sourceware dot org
2022-11-04 20:05 ` tromey at sourceware dot org
2022-11-04 20:10 ` simon.marchi at polymtl dot ca
2022-11-04 21:27 ` tromey at sourceware dot org
2022-11-04 21:28 ` tromey at sourceware dot org
2022-11-04 21:28 ` tromey at sourceware dot org
2022-11-05  1:28 ` simark at simark dot ca
2022-11-07 16:28 ` tromey at sourceware dot org
2022-11-16  0:09 ` tkacvins at gmail dot com
2022-11-16  0:56 ` simark at simark dot ca
2022-11-16 15:07 ` tkacvins at gmail dot com
2022-12-01 16:44 ` cvs-commit at gcc dot gnu.org
2022-12-01 18:18 ` cvs-commit at gcc dot gnu.org
2022-12-01 18:22 ` tromey at sourceware dot org
2022-12-14 10:23 ` cvs-commit 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-29105-4717-hIRUsywBf3@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: 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).