[00/14] Share DWARF partial symtabs between objfiles

Message ID 20200215165444.32653-1-tom@tromey.com
Headers show
Series
  • Share DWARF partial symtabs between objfiles
Related show

Message

Tom Tromey Feb. 15, 2020, 4:54 p.m.
A long-term goal for multi-inferior debugging has been to "split" an
objfile, so that the bulk of the data can be shared across inferiors.
Although a lot of progress has been made on this front, it has turned
out to be surprisingly difficult to fully implement.

"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.

Implementing this also turned out to be tricky; but unlike the
situation with types and symbols, it was possible to do incrementally.

This series implements this idea for DWARF.  It separates
dwarf2_per_objfile into shareable and unshareable parts; then, when
possible, the object is attached to the BFD.

You can see the difference when timing "add-inferior -exec ./gdb",
after "gdb ./gdb":

Before: Command execution time: 1.667661 (cpu), 1.687607 (wall)
After : Command execution time: 0.150011 (cpu), 0.151292 (wall)

In this series I did not rename dwarf2_per_objfile.  I'd prefer to do
this after landing this series; it seemed like a large, mostly
cosmetic, and yet hard-to-rebase patch.  Also, I wanted to consult
with everyone else about what we ought to call it.

I also didn't attempt to implement this sharing for CTF.  I don't
really know much about CTF; but it seems like it ought to be possible.
(Though I wonder if CTF wouldn't benefit more from simply bypassing
partial symbols entirely.)

Regression tested on x86-64 Fedora 28.  I also did various tests by
hand, and tested it by hand, under valgrind, on a gdb built with
-fdebug-types-section.

Like I mentioned earlier, this is a tricky series, so it would benefit
from careful review.  The main danger is that, if I missed a spot, we
could end up in a situation where gdb will crash in a multi-inferior
scenario.

Tom

Comments

Luis Machado Feb. 17, 2020, 12:31 p.m. | #1
On 2/15/20 1:54 PM, Tom Tromey wrote:
> A long-term goal for multi-inferior debugging has been to "split" an

> objfile, so that the bulk of the data can be shared across inferiors.

> Although a lot of progress has been made on this front, it has turned

> out to be surprisingly difficult to fully implement.

> 

> "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.

> 

> Implementing this also turned out to be tricky; but unlike the

> situation with types and symbols, it was possible to do incrementally.

> 

> This series implements this idea for DWARF.  It separates

> dwarf2_per_objfile into shareable and unshareable parts; then, when

> possible, the object is attached to the BFD.

> 

> You can see the difference when timing "add-inferior -exec ./gdb",

> after "gdb ./gdb":

> 


Out of curiosity, what use cases would this cover? I imagine symbol data 
could be shared, with a few exceptions, only with binaries that are 
equal to the one we've already loaded/we're already debugging.

Is this a common scenario? Would type-sharing also be a common scenario?
Tom Tromey Feb. 17, 2020, 4:58 p.m. | #2
>>>>> "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
Tom de Vries Feb. 22, 2020, 9:50 p.m. | #3
On 15-02-2020 17:54, Tom Tromey wrote:
> A long-term goal for multi-inferior debugging has been to "split" an

> objfile, so that the bulk of the data can be shared across inferiors.

> Although a lot of progress has been made on this front, it has turned

> out to be surprisingly difficult to fully implement.

> 

> "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.

> 

> Implementing this also turned out to be tricky; but unlike the

> situation with types and symbols, it was possible to do incrementally.

> 

> This series implements this idea for DWARF.  It separates

> dwarf2_per_objfile into shareable and unshareable parts; then, when

> possible, the object is attached to the BFD.

> 

> You can see the difference when timing "add-inferior -exec ./gdb",

> after "gdb ./gdb":

> 

> Before: Command execution time: 1.667661 (cpu), 1.687607 (wall)

> After : Command execution time: 0.150011 (cpu), 0.151292 (wall)

> 

> In this series I did not rename dwarf2_per_objfile.  I'd prefer to do

> this after landing this series; it seemed like a large, mostly

> cosmetic, and yet hard-to-rebase patch.  Also, I wanted to consult

> with everyone else about what we ought to call it.

> 

> I also didn't attempt to implement this sharing for CTF.  I don't

> really know much about CTF; but it seems like it ought to be possible.

> (Though I wonder if CTF wouldn't benefit more from simply bypassing

> partial symbols entirely.)

> 

> Regression tested on x86-64 Fedora 28.  I also did various tests by

> hand, and tested it by hand, under valgrind, on a gdb built with

> -fdebug-types-section.

> 

> Like I mentioned earlier, this is a tricky series, so it would benefit

> from careful review.  The main danger is that, if I missed a spot, we

> could end up in a situation where gdb will crash in a multi-inferior

> scenario.


I would like to take a look at this.

Is this tromey/t/reorganize-dwarf-code-sharing on your github?

Thanks,
- Tom
Tom Tromey Feb. 22, 2020, 10:01 p.m. | #4
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:


Tom> Is this tromey/t/reorganize-dwarf-code-sharing on your github?

Yes.  Thanks for looking.  Simon also mentioned that he wanted to try
some changes.  I don't plan to check this in until I hear back from him.
If you have concerns / changes, I'm happy to wait for your investigation
as well.

Tom
Simon Marchi Feb. 23, 2020, 2:37 a.m. | #5
On 2020-02-15 11:54 a.m., Tom Tromey wrote:
> A long-term goal for multi-inferior debugging has been to "split" an

> objfile, so that the bulk of the data can be shared across inferiors.

> Although a lot of progress has been made on this front, it has turned

> out to be surprisingly difficult to fully implement.

> 

> "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.

> 

> Implementing this also turned out to be tricky; but unlike the

> situation with types and symbols, it was possible to do incrementally.

> 

> This series implements this idea for DWARF.  It separates

> dwarf2_per_objfile into shareable and unshareable parts; then, when

> possible, the object is attached to the BFD.

> 

> You can see the difference when timing "add-inferior -exec ./gdb",

> after "gdb ./gdb":

> 

> Before: Command execution time: 1.667661 (cpu), 1.687607 (wall)

> After : Command execution time: 0.150011 (cpu), 0.151292 (wall)

> 

> In this series I did not rename dwarf2_per_objfile.  I'd prefer to do

> this after landing this series; it seemed like a large, mostly

> cosmetic, and yet hard-to-rebase patch.  Also, I wanted to consult

> with everyone else about what we ought to call it.

> 

> I also didn't attempt to implement this sharing for CTF.  I don't

> really know much about CTF; but it seems like it ought to be possible.

> (Though I wonder if CTF wouldn't benefit more from simply bypassing

> partial symbols entirely.)

> 

> Regression tested on x86-64 Fedora 28.  I also did various tests by

> hand, and tested it by hand, under valgrind, on a gdb built with

> -fdebug-types-section.

> 

> Like I mentioned earlier, this is a tricky series, so it would benefit

> from careful review.  The main danger is that, if I missed a spot, we

> could end up in a situation where gdb will crash in a multi-inferior

> scenario.

> 

> Tom


I've started to look at this, and this is my initial feeling (as discussed
with Tom on IRC).

This patch series implements:

  objfile -> dwarf2 object shared between objfiles -> dwarf2 objfile-specific object

With the last pointer getting updated at each entry point of the DWARF code to point
to the right "dwarf2 objfile-specific object" according to the context.

I think it would be more natural and easier to understand to have :

  objfile -> dwarf2 objfile-specific object -> dwarf2 object shared between objfiles

Many "dwarf2 objfile-specific" objects would point to one "dwarf2 object shared between
objfiles", without special tricks.  Of course, it's much easier said than done.

I'd like to know: did you consider this way of doing it and chose not to do it
because of the complexity / size of the change?  Is the current patchset a stepping
stone towards it?

Simon
Tom Tromey Feb. 23, 2020, 11:58 p.m. | #6
>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:


Simon> I think it would be more natural and easier to understand to have :

Simon>   objfile -> dwarf2 objfile-specific object -> dwarf2 object shared between objfiles

Simon> Many "dwarf2 objfile-specific" objects would point to one "dwarf2 object shared between
Simon> objfiles", without special tricks.  Of course, it's much easier said than done.

Simon> I'd like to know: did you consider this way of doing it and chose not to do it
Simon> because of the complexity / size of the change?  Is the current patchset a stepping
Simon> stone towards it?

I was afraid of the size of the resulting patch.  However, I think
you're right that this would be better.  And, I feel pretty strongly
that we should be making the DWARF reader less awful, not more.

Probably the thing to do is reorder the series a little (some patches
don't depend on this), then redo the "unsharing" patch, and finally
update the subsequent patches.

A few of these patches (1-3, 5, and 11) could probably go in sooner.
What do you think of that?

Tom
Simon Marchi Feb. 24, 2020, 2:52 a.m. | #7
On 2020-02-23 6:58 p.m., Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

> 

> Simon> I think it would be more natural and easier to understand to have :

> 

> Simon>   objfile -> dwarf2 objfile-specific object -> dwarf2 object shared between objfiles

> 

> Simon> Many "dwarf2 objfile-specific" objects would point to one "dwarf2 object shared between

> Simon> objfiles", without special tricks.  Of course, it's much easier said than done.

> 

> Simon> I'd like to know: did you consider this way of doing it and chose not to do it

> Simon> because of the complexity / size of the change?  Is the current patchset a stepping

> Simon> stone towards it?

> 

> I was afraid of the size of the resulting patch.  However, I think

> you're right that this would be better.  And, I feel pretty strongly

> that we should be making the DWARF reader less awful, not more.


Yeah, as I already showed you, I started making such a patch (more details
below).  I think it's worth doing this work, because in the end it's easier
to follow the code.  I find that the dwarf2_enter_objfile approach is
analogous to having to set a "current context" (e.g. call switch_to_thread)
before calling a certain function, which goes against what we are trying
to do in general (for example, trying to change functions to accept a
thread / ptid rather than rely on inferior_ptid).

Since dwarf2_per_cu_data objects become objfile-independent, functions that
need to work on a dwarf2_per_cu_data in an objfile-dependent way then need
to accept an objfile or dwarf2_per_objfile object along with the
dwarf2_per_cu_data.  It's a bit tedious, but in the end it forces us to pass
the objfile context all the way from the callers, and it's less likely that
we forget a spot, like we could with dwarf2_enter_objfile, since it would just
not compile.

> Probably the thing to do is reorder the series a little (some patches

> don't depend on this), then redo the "unsharing" patch, and finally

> update the subsequent patches.

> 

> A few of these patches (1-3, 5, and 11) could probably go in sooner.

> What do you think of that?


#1 is already in, right?
#2: Yes, sounds like a good cleanup.
#4: Yes, good cleanup.

#3: It's only useful if we end up doing psymtabs sharing, so I would not push
    it yet.
#5 and #11: I'm not sure how much of that I end up un-doing in my prototype patch,
    swapping the shareable and unshareable parts.  And it is also only useful in
    the context of psymtab sharing, so I wouldn't push it yet.

I'm currently experimenting with what I suggested above, this is what I have for
now (this will get force-pushed as I progress):

  https://github.com/simark/binutils-gdb/commits/share-psymtabs

The status is: I'm based on your patch 9/14 ("Add objfile member to DWARF batons"),
as it aims mainly to replace patch patch 10/14 ("Introduce dwarf2_enter_objfile and
use it") with the architecture I proposed.  I see no regression in a simple
"make check" between it and the previous commit.  I have yet to apply and adapt the
rest of your series on top of my commit.  I would also like to test with the variety
of testsuite boards that Tom de Vries added, since they will test various DWARF
configurations (and I would feel bad if he had to clean up after us again).

Simon
Tom Tromey Feb. 24, 2020, 3:07 a.m. | #8
>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:


>> A few of these patches (1-3, 5, and 11) could probably go in sooner.

>> What do you think of that?


Simon> #1 is already in, right?
Simon> #2: Yes, sounds like a good cleanup.
Simon> #4: Yes, good cleanup.

Simon> #3: It's only useful if we end up doing psymtabs sharing, so I would not push
Simon>     it yet.
Simon> #5 and #11: I'm not sure how much of that I end up un-doing in my prototype patch,
Simon>     swapping the shareable and unshareable parts.  And it is also only useful in
Simon>     the context of psymtab sharing, so I wouldn't push it yet.

Ugh, I used the wrong numbers.

#1 is already in, so really I mean #2-#4, #6, #12.

#2 (simplify setting of reading_partial_symbols)
#3 dwarf2_per_objfile::obstack
#4 TYPE_UNIT_GROUP method
#6 Add "objfile" parameter to two partial_symtab methods
#12 Fix a memory leak

Maybe the baton change could be done as well.

Simon> I'm currently experimenting with what I suggested above, this is what I have for
Simon> now (this will get force-pushed as I progress):

Simon>   https://github.com/simark/binutils-gdb/commits/share-psymtabs

Simon> The status is: I'm based on your patch 9/14 ("Add objfile member to DWARF batons"),
Simon> as it aims mainly to replace patch patch 10/14 ("Introduce dwarf2_enter_objfile and
Simon> use it") with the architecture I proposed.  I see no regression in a simple
Simon> "make check" between it and the previous commit.  I have yet to apply and adapt the
Simon> rest of your series on top of my commit.  I would also like to test with the variety
Simon> of testsuite boards that Tom de Vries added, since they will test various DWARF
Simon> configurations (and I would feel bad if he had to clean up after us again).

Yeah.

Take a look at my branch, t/reorganize-dwarf-code-sharing-3.
I rearranged it to move all the "unshared" stuff to the end, so there
should be less to fix up (though I see now I neglected to move the baton
patch earlier).

Tom
Tom Tromey Feb. 24, 2020, 3:22 a.m. | #9
Tom> Take a look at my branch, t/reorganize-dwarf-code-sharing-3.
Tom> I rearranged it to move all the "unshared" stuff to the end, so there
Tom> should be less to fix up (though I see now I neglected to move the baton
Tom> patch earlier).

I made this change, so now the branch looks like (order is reversed from
how git send-email would send it):

 0 eeeb07c1120 Share DWARF partial symtabs
 1 597fab7df48 Move signatured_type::type to unshareable object
 2 9ec85b37d88 Split type_unit_group
 3 f4d2c85a250 Introduce dwarf2_enter_objfile and use it
 4 afcc2a6d028 Remove symtab links from dwarf2_psymtab and dwarf2_per_cu_quick_data
 5 11fad00951b Introduce dwarf2_unshareable and move die_type_hash
 6 49fe37ffefb Add objfile member to DWARF batons
 7 842794fd4d9 Add dwarf2_per_cu_data::index
 8 cbf63c32179 Fix a memory leak and remove an unused member
 9 fe38cf467e1 Add "objfile" parameter to two partial_symtab methods
10 e0e096e6956 Convert IS_TYPE_UNIT_GROUP to method
11 ad71f2eb272 Introduce dwarf2_per_objfile::obstack
12 4a127c55a71 Simplify setting of reading_partial_symbols


Basically I think switching the sharing would start at patch #5, and
then parts of patch #0 would be salvaged, but not most of the rest of
patches #1-#5.

Also I have another patch here that adds a subclass of partial_symtab
for DWARF includes.  I *think* this solves the need to wrap the
compunit_symtab pointer in an optional<>, though it remains hard to be
completely certain.  I'll send that sometime soon, I think it could go
in separately.

Tom
Tom de Vries Feb. 24, 2020, 1:42 p.m. | #10
On 24-02-2020 04:22, Tom Tromey wrote:
> Tom> Take a look at my branch, t/reorganize-dwarf-code-sharing-3.


FWIW, I tried to build this earlier today and ran into a build error. [
Sorry, don't have the specifics available right now, my laptop is tied
up building a series of commits. ]

Thanks,
- Tom
Tom de Vries Feb. 24, 2020, 4 p.m. | #11
On 24-02-2020 14:42, Tom de Vries wrote:
> On 24-02-2020 04:22, Tom Tromey wrote:

>> Tom> Take a look at my branch, t/reorganize-dwarf-code-sharing-3.

> 

> FWIW, I tried to build this earlier today and ran into a build error. [

> Sorry, don't have the specifics available right now, my laptop is tied

> up building a series of commits. ]

> 


Here it is:
...
src/gdb/dwarf2/read.c:10967:41: error: macro "XOBNEWVEC" requires 3
arguments, but only 2 given
          line_header->file_names_size ());
                                         ^
src/gdb/dwarf2/read.c: In member function 'void
dwarf2_cu::setup_type_unit_groups(die_info*)':
/data/gdb_versions/devel/src/gdb/dwarf2/read.c:10966:17: error: 'struct
type_unit_group' has no member named 'symtabs'
       tu_group->symtabs = XOBNEWVEC (struct symtab *,
                 ^~~~~~~
src/gdb/dwarf2/read.c:10966:27: error: 'XOBNEWVEC' was not declared in
this scope
       tu_group->symtabs = XOBNEWVEC (struct symtab *,
                           ^~~~~~~~~
make[1]: *** [Makefile:1600: dwarf2/read.o] Error 1
...

Thanks,
- Tom
Tom Tromey Feb. 24, 2020, 5:29 p.m. | #12
>> FWIW, I tried to build this earlier today and ran into a build error. [

>> Sorry, don't have the specifics available right now, my laptop is tied

>> up building a series of commits. ]


Sorry about that.  I'll fix it up later.

Tom
Simon Marchi Feb. 24, 2020, 7:18 p.m. | #13
On 2020-02-23 10:22 p.m., Tom Tromey wrote:
> Tom> Take a look at my branch, t/reorganize-dwarf-code-sharing-3.

> Tom> I rearranged it to move all the "unshared" stuff to the end, so there

> Tom> should be less to fix up (though I see now I neglected to move the baton

> Tom> patch earlier).

> 

> I made this change, so now the branch looks like (order is reversed from

> how git send-email would send it):

> 

>  0 eeeb07c1120 Share DWARF partial symtabs

>  1 597fab7df48 Move signatured_type::type to unshareable object

>  2 9ec85b37d88 Split type_unit_group

>  3 f4d2c85a250 Introduce dwarf2_enter_objfile and use it

>  4 afcc2a6d028 Remove symtab links from dwarf2_psymtab and dwarf2_per_cu_quick_data

>  5 11fad00951b Introduce dwarf2_unshareable and move die_type_hash

>  6 49fe37ffefb Add objfile member to DWARF batons

>  7 842794fd4d9 Add dwarf2_per_cu_data::index

>  8 cbf63c32179 Fix a memory leak and remove an unused member

>  9 fe38cf467e1 Add "objfile" parameter to two partial_symtab methods

> 10 e0e096e6956 Convert IS_TYPE_UNIT_GROUP to method

> 11 ad71f2eb272 Introduce dwarf2_per_objfile::obstack

> 12 4a127c55a71 Simplify setting of reading_partial_symbols

> 

> 

> Basically I think switching the sharing would start at patch #5, and

> then parts of patch #0 would be salvaged, but not most of the rest of

> patches #1-#5.


Ok, thanks for doing this.

I don't undersatnd why you say that patches #1-#5 won't be salvaged, I think
they will still be necessary.  For example, #1 and #2 are still necessary to
take out objfile-specific parts from dwarf2_per_cu_data, aren't they?

I would just replace patch #4 (with probably a few consecutive patches), and
probably alter patch #5 to maybe change the naming.

Naming-wise, I'm planning to use:

  objfile -> dwarf2_per_objfile -> dwarf2_shared_between_objfiles

I find the last one a bit long, although it's clear.  I'm open to any suggestions.

I am also thinking of renaming dwarf2_per_cu_data to just dwarf2_per_cu.  I think it
would be coherent with dwarf2_per_objfile.

> Also I have another patch here that adds a subclass of partial_symtab

> for DWARF includes.  I *think* this solves the need to wrap the

> compunit_symtab pointer in an optional<>, though it remains hard to be

> completely certain.  I'll send that sometime soon, I think it could go

> in separately.


I don't really know about that and the current work uses enough of my brain
cycles, so I could take a look, but only once we are done with the current
series (unless you think it impacts the current series).

Simon
Tom Tromey Feb. 24, 2020, 10:48 p.m. | #14
Simon> #1 is already in, right?
Simon> #2: Yes, sounds like a good cleanup.
Simon> #4: Yes, good cleanup.

I'm going to push these soon.

Tom
Tom Tromey Feb. 24, 2020, 11:15 p.m. | #15
>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:


>>> FWIW, I tried to build this earlier today and ran into a build error. [

>>> Sorry, don't have the specifics available right now, my laptop is tied

>>> up building a series of commits. ]


Tom> Sorry about that.  I'll fix it up later.

I pushed the 3 simpler fixes to master, rebased my branch again, fixed
the build bugs, and force-pushed it to my github again.

Tom
Tom Tromey Feb. 24, 2020, 11:20 p.m. | #16
>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:


>> 0 eeeb07c1120 Share DWARF partial symtabs

>> 1 597fab7df48 Move signatured_type::type to unshareable object

>> 2 9ec85b37d88 Split type_unit_group

>> 3 f4d2c85a250 Introduce dwarf2_enter_objfile and use it

>> 4 afcc2a6d028 Remove symtab links from dwarf2_psymtab and dwarf2_per_cu_quick_data

>> 5 11fad00951b Introduce dwarf2_unshareable and move die_type_hash

>> 6 49fe37ffefb Add objfile member to DWARF batons

>> 7 842794fd4d9 Add dwarf2_per_cu_data::index

>> 8 cbf63c32179 Fix a memory leak and remove an unused member

>> 9 fe38cf467e1 Add "objfile" parameter to two partial_symtab methods

>> 10 e0e096e6956 Convert IS_TYPE_UNIT_GROUP to method

>> 11 ad71f2eb272 Introduce dwarf2_per_objfile::obstack

>> 12 4a127c55a71 Simplify setting of reading_partial_symbols


Simon> I don't undersatnd why you say that patches #1-#5 won't be salvaged, I think
Simon> they will still be necessary.  For example, #1 and #2 are still necessary to
Simon> take out objfile-specific parts from dwarf2_per_cu_data, aren't they?

Yeah, I suppose so.  I think the goal should be to eliminate the
dwarf2_enter_objfile stuff, so I suppose really only one patch would be
wholly gone; and dwarf2_unshareable changed to sort of the "opposite"
patch.

Simon>   objfile -> dwarf2_per_objfile -> dwarf2_shared_between_objfiles

Simon> I find the last one a bit long, although it's clear.  I'm open to
Simon> any suggestions.

We talked on irc and thought dwarf2_per_bfd sounded ok, given that this
naming is already used for objfile data.

>> Also I have another patch here that adds a subclass of partial_symtab

>> for DWARF includes.  I *think* this solves the need to wrap the

>> compunit_symtab pointer in an optional<>, though it remains hard to be

>> completely certain.  I'll send that sometime soon, I think it could go

>> in separately.


Simon> I don't really know about that and the current work uses enough of my brain
Simon> cycles, so I could take a look, but only once we are done with the current
Simon> series (unless you think it impacts the current series).

If it could eliminate the optional, it would simplify some of the code.
I'll look at that a bit.

Tom