From: Jim Blandy <jimb@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com, Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [RFA/dwarf] Don't process types multiple times
Date: Fri, 12 Mar 2004 23:45:00 -0000 [thread overview]
Message-ID: <vt28yi5eikk.fsf@zenia.home> (raw)
In-Reply-To: <20040225044206.GA23242@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> This independent patch is a performance and correctness fix for full symbol
> processing. My description from the intercu branch posting:
>
> There are two ways that we can process a general DIE: process_die or
> read_type_die. Children of particular DIE types may be processed directly,
> but these are the only major dispatch points. It's interesting to notice
> that almost everything called from read_type_die starts with "if (die->type)
> return": everything but enumeration types and aggregate types, in fact.
> This means that if the first reference to an enumeration or aggregate type
> is a DW_AT_type or DW_AT_containing_type in a DIE numerically before the
> type's DIE, we'll end up calling new_symbol for it twice.
>
> Fixing this saves about 8% memory and 4% time from gdb -readnow libc.so.6,
> a lot of duplicate entries on maint print symbols which I vaguely recall
> being confused about but never investigated, and some serious problems for
> inter-CU support. Without this, types could be added to the wrong symbol
> table.
>
> Tested i686-pc-linux-gnu, no regressions. OK to commit?
So the essential idea here is to make sure that we only create symbols
when we reach them via the main traversal, not when we happen to reach
them by following references with die_type. The current code relies
on the existing read_structure_scope and read_enumeration functions to
both read the type and create the symbol, so it can't distinguish
between the two cases. Your patch creates a separate function for
each role, and ensures that the symbol creation functions are only
called from the main traversal.
Is that right? If so, please commit, to trunk and branch.
One suggestion: for the aggregate types, it seems like we're using
"read_structure_scope" to mean "create the type object, but don't call
new_symbol", and "process_structure_scope" to mean "go ahead and
create the new symbols". But for the enumerations, the two
corresponding functions are called "read_enumeration_type" and
"read_enumeration_scope". Their functions are parallel, but the names
don't reflect it. So how about:
don't make sym make sym
struct: read_structure_scope process_structure_scope
enum: read_enumeration_scope process_enumeration_scope
or:
struct: read_structure_type process_structure_scope
enum: read_enumeration_type process_enumeration_scope
WARNING: multiple messages have this Message-ID
From: Jim Blandy <jimb@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com, Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [RFA/dwarf] Don't process types multiple times
Date: Fri, 19 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <vt28yi5eikk.fsf@zenia.home> (raw)
Message-ID: <20040319000900.uCOBdMMdLbQqY3fvZ7O7BKgsJg022qehy0M7QS809Ak@z> (raw)
In-Reply-To: <20040225044206.GA23242@nevyn.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> This independent patch is a performance and correctness fix for full symbol
> processing. My description from the intercu branch posting:
>
> There are two ways that we can process a general DIE: process_die or
> read_type_die. Children of particular DIE types may be processed directly,
> but these are the only major dispatch points. It's interesting to notice
> that almost everything called from read_type_die starts with "if (die->type)
> return": everything but enumeration types and aggregate types, in fact.
> This means that if the first reference to an enumeration or aggregate type
> is a DW_AT_type or DW_AT_containing_type in a DIE numerically before the
> type's DIE, we'll end up calling new_symbol for it twice.
>
> Fixing this saves about 8% memory and 4% time from gdb -readnow libc.so.6,
> a lot of duplicate entries on maint print symbols which I vaguely recall
> being confused about but never investigated, and some serious problems for
> inter-CU support. Without this, types could be added to the wrong symbol
> table.
>
> Tested i686-pc-linux-gnu, no regressions. OK to commit?
So the essential idea here is to make sure that we only create symbols
when we reach them via the main traversal, not when we happen to reach
them by following references with die_type. The current code relies
on the existing read_structure_scope and read_enumeration functions to
both read the type and create the symbol, so it can't distinguish
between the two cases. Your patch creates a separate function for
each role, and ensures that the symbol creation functions are only
called from the main traversal.
Is that right? If so, please commit, to trunk and branch.
One suggestion: for the aggregate types, it seems like we're using
"read_structure_scope" to mean "create the type object, but don't call
new_symbol", and "process_structure_scope" to mean "go ahead and
create the new symbols". But for the enumerations, the two
corresponding functions are called "read_enumeration_type" and
"read_enumeration_scope". Their functions are parallel, but the names
don't reflect it. So how about:
don't make sym make sym
struct: read_structure_scope process_structure_scope
enum: read_enumeration_scope process_enumeration_scope
or:
struct: read_structure_type process_structure_scope
enum: read_enumeration_type process_enumeration_scope
next prev parent reply other threads:[~2004-03-12 23:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 4:42 Daniel Jacobowitz
2004-02-25 17:02 ` David Carlton
2004-03-05 2:55 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-12 23:45 ` Jim Blandy [this message]
2004-03-15 22:08 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Jim Blandy
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-14 21:10 ` Daniel Jacobowitz
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=vt28yi5eikk.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=drow@false.org \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/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