From: Tom Tromey <tom@tromey.com>
To: Luis Machado <luis.machado@linaro.org>
Cc: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 00/14] Share DWARF partial symtabs between objfiles
Date: Mon, 17 Feb 2020 16:59:00 -0000 [thread overview]
Message-ID: <87k14l9mlr.fsf@tromey.com> (raw)
In-Reply-To: <3b7ccfdc-0c9b-4322-d087-1cffa8bf7c4d@linaro.org> (Luis Machado's message of "Mon, 17 Feb 2020 09:31:18 -0300")
>>>>> "Luis" == Luis Machado <luis.machado@linaro.org> writes:
>> "Recently" (a year or two ago) I realized that we could get most of
>> the benefits of this split by sharing partial symbol tables. This is
>> true because reading partial symbols is the slowest operation that
>> users see -- in most cases, expanding a full symtab is reasonably
>> quick.
Luis> Out of curiosity, what use cases would this cover? I imagine symbol
Luis> data could be shared, with a few exceptions, only with binaries that
Luis> are equal to the one we've already loaded/we're already debugging.
Luis> Is this a common scenario?
I think it's uncommon right now, because multi-inferior debugging is
uncommon in general.
For multi-inferior debugging, I guess it would be more common for this
reuse to happen for shared libraries than for executables.
For instance, when debugging Firefox, most of the symbols are in one
giant shared library, libxul. It is loaded once by the launcher, which
then execs and the new inferior loads it again. (This case, I think,
still isn't handled -- there's no mechanism for preserving the BFD
across an exec yet.) And then, Firefox is now multi-process, and each
such process also loads libxul. So here at least, it would be a big
improvement.
> Would type-sharing also be a common scenario?
IMO the ideal would be for all symbols and types to be
objfile-independent. The data does not inherently need to be
objfile-dependent, it is just an accident of history, where some earlier
programmer decided to bake the objfile offsets into symbol addresses.
We've made this transformation (to remove the offset from the
representation) for minimal and partial symbols, but for full symbols it
is just a lot harder to untangle everything.
Types, maybe surprisingly, fall into this because types can link to
symbols (see cplus_struct_type::template_arguments).
Tom
next prev parent reply other threads:[~2020-02-17 16:59 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-15 16:54 Tom Tromey
2020-02-15 16:55 ` [PATCH 07/14] Add dwarf2_per_cu_data::index Tom Tromey
2020-02-18 11:39 ` Luis Machado
2020-02-21 23:36 ` Tom Tromey
2020-02-19 4:36 ` Simon Marchi
2020-02-19 5:31 ` Simon Marchi
2020-02-21 23:41 ` Tom Tromey
2020-02-21 23:41 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 06/14] Add "objfile" parameter to two partial_symtab methods Tom Tromey
2020-02-18 11:26 ` Luis Machado
2020-02-15 16:55 ` [PATCH 10/14] Introduce dwarf2_enter_objfile and use it Tom Tromey
2020-02-18 11:58 ` Luis Machado
2020-02-21 22:54 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 05/14] Introduce dwarf2_unshareable and move die_type_hash Tom Tromey
2020-02-18 11:23 ` Luis Machado
2020-02-19 4:20 ` Simon Marchi
2020-02-21 22:43 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 14/14] Share DWARF partial symtabs Tom Tromey
2020-02-18 12:26 ` Luis Machado
2020-02-21 23:03 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 03/14] Introduce dwarf2_per_objfile::obstack Tom Tromey
2020-02-19 4:13 ` Simon Marchi
2020-02-22 0:44 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 11/14] Split type_unit_group Tom Tromey
2020-02-18 12:08 ` Luis Machado
2020-02-22 0:40 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 02/14] Simplify setting of reading_partial_symbols Tom Tromey
2020-02-15 16:55 ` [PATCH 12/14] Fix a memory leak and remove an unused member Tom Tromey
2020-02-15 16:55 ` [PATCH 09/14] Add objfile member to DWARF batons Tom Tromey
2020-02-15 16:55 ` [PATCH 01/14] Fix latent bug in dwarf2_find_containing_comp_unit Tom Tromey
2020-02-19 3:42 ` Simon Marchi
2020-02-19 14:08 ` Tom Tromey
2020-02-20 0:11 ` Tom Tromey
2020-02-20 0:12 ` Tom Tromey
[not found] ` <3a3f1f39-c715-58ba-06a8-2980afb82c53@simark.ca>
2020-02-20 16:50 ` Tom Tromey
2020-03-07 19:12 ` Christian Biesinger
2020-02-15 16:55 ` [PATCH 13/14] Move signatured_type::type to unshareable object Tom Tromey
2020-02-15 16:55 ` [PATCH 08/14] Remove symtab links from dwarf2_psymtab and dwarf2_per_cu_quick_data Tom Tromey
2020-02-18 11:50 ` Luis Machado
2020-02-19 4:47 ` Simon Marchi
2020-02-22 0:38 ` Tom Tromey
2020-02-22 0:36 ` Tom Tromey
2020-02-15 16:55 ` [PATCH 04/14] Convert IS_TYPE_UNIT_GROUP to method Tom Tromey
2020-02-17 12:31 ` [PATCH 00/14] Share DWARF partial symtabs between objfiles Luis Machado
2020-02-17 16:59 ` Tom Tromey [this message]
2020-02-22 21:50 ` Tom de Vries
2020-02-22 22:01 ` Tom Tromey
2020-02-23 2:37 ` Simon Marchi
2020-02-23 23:58 ` Tom Tromey
2020-02-24 2:52 ` Simon Marchi
2020-02-24 3:07 ` Tom Tromey
2020-02-24 3:22 ` Tom Tromey
2020-02-24 13:42 ` Tom de Vries
2020-02-24 16:00 ` Tom de Vries
2020-02-24 17:29 ` Tom Tromey
2020-02-24 23:15 ` Tom Tromey
2020-02-24 19:18 ` Simon Marchi
2020-02-24 23:20 ` Tom Tromey
2020-02-24 22:48 ` 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=87k14l9mlr.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@linaro.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