From: Daniel Jacobowitz <drow@false.org>
To: gdb@sources.redhat.com
Subject: Branch created for inter-compilation-unit references
Date: Sat, 21 Feb 2004 20:08:00 -0000 [thread overview]
Message-ID: <20040221200814.GA28652@nevyn.them.org> (raw)
I've just created "drow_intercu-20040221-branch". I'm going to post and
commit the work I've done over the past two days, which starts at the
opposite end of the problem from several approaches I've seen here in the
past.
At present we could safely ignore the case of partial symbol tables. The
only inter-die reference that we would even examine during partial symbol
table building is DW_AT_specification (and similar), for the names of
DIEs whose specification is in a namespace. And generally we have a mangled
name so the fallback that David checked in some weeks ago works OK.
But one of the long-term goals for inter-CU support is to decrease the total
size of debug information. One way to do that is separating header DIEs
into separate compilation units; but another important way is to scrap
DW_AT_MIPS_linkage_name. I don't want to add a new dependence on the
mangled names that I would just have to clean up later.
So I've begun with the partial symbol tables. I haven't actually added any
inter-CU support yet; only support within a single CU for following
DW_AT_specification. I load all necessary DIEs into memory before parsing
any, with a couple of exceptions for speed. I build sibling and child
chains like we do for full DIEs. This is where the performance cost comes
in: the two big hitters are adding the DIEs I want to save to the hash
table, and data cache misses from separating the loading and processing
of the DIE.
My focus so far has been on not increasing startup time for C (primarily) or
C++ (secondarily) applications; I am within about 4% for C and about 8% for
C++. I think that will be acceptable for now - there's room for about 10%
improvement in other parts of GDB for C and 30% for C++, based on my
profiling, and I will pursue it later. Probably before merging this code.
Next will be real inter-CU support for partial symbols. Then for full
symbols. My hope is that I can do both of those without perturbing the
non-inter-CU path too much.
GCC HEAD can already generate the necessary debug information if you want to
play with it; use -gdwarf-2 -feliminate-dwarf2-dups. I expect it will be at
least a few more days before GDB can read that output.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next reply other threads:[~2004-02-21 20:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-21 20:08 Daniel Jacobowitz [this message]
2004-02-25 0:18 ` Daniel Jacobowitz
2004-02-25 0:35 ` Andrew Cagney
2004-02-25 1:29 ` Daniel Jacobowitz
2004-02-25 2:23 ` Andrew Cagney
2004-02-25 2:27 ` Daniel Jacobowitz
2004-02-25 3:17 ` Andrew Cagney
2004-02-25 3:51 Michael Elizabeth Chastain
2004-02-25 5:12 ` Andrew Cagney
2004-02-25 16:10 ` Daniel Berlin
2004-02-25 17:01 ` Andrew Cagney
2004-02-25 17:07 ` Daniel Berlin
2004-02-25 18:50 ` Andrew Cagney
2004-02-25 18:53 ` Daniel Berlin
2004-02-25 19:48 ` Andrew Cagney
2004-02-26 5:48 ` Eli Zaretskii
2004-02-26 6:06 ` Daniel Berlin
2004-02-26 6:31 ` Eli Zaretskii
2004-02-26 15:05 ` Daniel Jacobowitz
2004-02-26 16:19 ` Elena Zannoni
2004-02-26 16:25 ` Daniel Jacobowitz
2004-02-26 16:36 ` Elena Zannoni
2004-02-26 16:54 ` Daniel Jacobowitz
2004-02-26 19:01 ` Eli Zaretskii
2004-02-26 19:10 ` Eli Zaretskii
2004-02-26 19:24 ` Andrew Cagney
2004-02-26 19:28 ` Daniel Jacobowitz
2004-02-26 20:19 ` Andrew Cagney
2004-02-26 5:48 ` Eli Zaretskii
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=20040221200814.GA28652@nevyn.them.org \
--to=drow@false.org \
--cc=gdb@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