[0/3] DWARF type signature lookup fallback.

  I am working on a patch that adds parameters to allow type signature fallback for DWARF type units to fallback to other objfiles.
This allows to only create type units once and reuse them by their type signature, reducing duplication of type units.
It builds on the uniqueness of type signatures, so a type signature always references the same type unit.

This is my first time using a mailing list, so please remind me of any formatting errors or other mistakes.

Thanks,
Dominik

dominikmascherbauer (3):
  Add new commands for controlling type signature fallback.
  Add type signature fallback and JIT objfile restriction.
  Add testing for type signature fallback.

 gdb/NEWS                                      |  14 +
 gdb/doc/gdb.texinfo                           |  26 ++
 gdb/dwarf2/read.c                             | 254 ++++++++++++++++--
 gdb/jit.c                                     |   6 +-
 gdb/objfile-flags.h                           |   3 +
 .../gdb.dwarf2/sig-type-fallback-jit.c        |  62 +++++
 .../gdb.dwarf2/sig-type-fallback-jit.exp      |  75 ++++++
 7 files changed, 409 insertions(+), 31 deletions(-)
 create mode 100644 gdb/testsuite/gdb.dwarf2/sig-type-fallback-jit.c
 create mode 100644 gdb/testsuite/gdb.dwarf2/sig-type-fallback-jit.exp


base-commit: 512316811d47d689d75d25aa9d5b98bdafd64df6
  

>>>>> dominikmascherbauer  <dominik.mascherbauer@gmail.com> writes:

> I am working on a patch that adds parameters to allow type signature
> fallback for DWARF type units to fallback to other objfiles.  This
> allows to only create type units once and reuse them by their type
> signature, reducing duplication of type units.  It builds on the
> uniqueness of type signatures, so a type signature always references
> the same type unit.

I am not sure this can really work due to lifetime constraints.

GDB has some rules about type ownership:

1. Arch-owned types must only refer to other arch-owned types

2. Objfile-owned types must only refer to other types coming from the
   same objfile, or to arch-owned types

These rules exist so that if an objfile is removed, there will not be
any dangling pointers.

I think this series violates rule 2.

There's a follow-on rule to this that isn't as frequently discussed, but
a symbol in an objfile has to follow rule 2 as well: it can't refer to
types from another objfile.  And I think this series also violates this.

I think you can see this in action for opaque types, where the lookup is
done over and over, because caching the result would violate the rules.
(This brings up the question of why you want this feature at all as
opposed to just using opaque type resolution.)


Anyway, this can't be easily remedied.  One idea we have discussed in
the past is to have a "type GC".  What this would mean is removing type
ownership -- just allocate all types globally.  Then, have a garbage
collector that removes type objects when things change, for instance
after an objfile is destroyed.

This is difficult to implement though.  For one thing types can refer
back to symbols.  Though perhaps this particular special case could be
handled by the GC.

Maybe other approaches are possible too, I don't know.

Tom
  

>>>>>> dominikmascherbauer  <dominik.mascherbauer@gmail.com> writes:
> 
>> I am working on a patch that adds parameters to allow type signature
>> fallback for DWARF type units to fallback to other objfiles.  This
>> allows to only create type units once and reuse them by their type
>> signature, reducing duplication of type units.  It builds on the
>> uniqueness of type signatures, so a type signature always references
>> the same type unit.
> 
> I am not sure this can really work due to lifetime constraints.
> 
> GDB has some rules about type ownership:
> 
> 1. Arch-owned types must only refer to other arch-owned types
> 
> 2. Objfile-owned types must only refer to other types coming from the
>    same objfile, or to arch-owned types
> 
> These rules exist so that if an objfile is removed, there will not be
> any dangling pointers.
> 
> I think this series violates rule 2.
> 
> There's a follow-on rule to this that isn't as frequently discussed, but
> a symbol in an objfile has to follow rule 2 as well: it can't refer to
> types from another objfile.  And I think this series also violates this.
> 
> I think you can see this in action for opaque types, where the lookup is
> done over and over, because caching the result would violate the rules.
> (This brings up the question of why you want this feature at all as
> opposed to just using opaque type resolution.)
> 
> 
> Anyway, this can't be easily remedied.  One idea we have discussed in
> the past is to have a "type GC".  What this would mean is removing type
> ownership -- just allocate all types globally.  Then, have a garbage
> collector that removes type objects when things change, for instance
> after an objfile is destroyed.
> 
> This is difficult to implement though.  For one thing types can refer
> back to symbols.  Though perhaps this particular special case could be
> handled by the GC.
> 
> Maybe other approaches are possible too, I don't know.
> 
> Tom

Thanks for the response.  I agree that this series violates rule 2 as you 
mentioned.  I was not aware of those rules at the time of implementing
this patch.

Thank you very much for pointing out opaque types.  I did not come across
those when trying to figure out how to reference existing types from other
objfiles.  For checking available options I mainly used the DWARF specification
which does not mention them.

My initial idea was to use type signatures as they should be unique even
across multiple objfiles.  Based on that I thought it would be possible
to use type signatures for finding type units in other not linked 
objfiles such as objfiles coming from the JIT compilation interface.

I tested opaque types for my use-case, and it did work out.  So, I guess the
best option for me is to adapt the generated debug info for opaque types.

Thanks again,
Dominik
  

>>>>> "Dominik" == Dominik Mascherbauer <dominik.mascherbauer@gmail.com> writes:

Dominik> Thanks for the response.  I agree that this series violates rule 2 as you 
Dominik> mentioned.  I was not aware of those rules at the time of implementing
Dominik> this patch.

Totally understandable, since if they are written down anywhere, it's in
some comment "somewhere".

Dominik> My initial idea was to use type signatures as they should be unique even
Dominik> across multiple objfiles.  Based on that I thought it would be possible
Dominik> to use type signatures for finding type units in other not linked 
Dominik> objfiles such as objfiles coming from the JIT compilation interface.

FWIW I think your insight here is correct.

Dominik> I tested opaque types for my use-case, and it did work out.  So, I guess the
Dominik> best option for me is to adapt the generated debug info for opaque types.

I wonder if integrating type signatures into 'struct type' would be
possible.  That is, an opaque type could store its signature.  Then
there'd be a new "quick" API method to look up a full type (which gdb
confusingly calls "transparent") by signature.

This might solve your problem without violating the lifetime rules and
without requiring type GC.

thanks,
Tom