[00/30] Baby step for objfile splitting

  Every year or so, I take a stab at the objfile splitting work.  This
always fails and I end up not sending anything.

This year, I decided to take a baby step instead, thinking maybe it
would be possible to slowly grind away at the problem.

This series is the first such step.  It spreads the use of
block_symbol through a bunch of code, trying to eliminate calls to
symbol::value_address.

The longer term idea here is to then add an objfile member to
block_symbol.  After this, it would be relatively simple to change
symbols to be relocated at point of use.  (This would be a significant
step toward objfile splitting, but there's even more to do after
that...)

Regression tested on x86-64 Fedora 38.

---
Tom Tromey (30):
      Introduce block-symbol.h
      Add block_symbol::address
      Easy conversions to use block_symbol::address
      Use block_symbol::address in ada-tasks.c
      Use block_symbol::address in printcmd.c
      Use block_symbol::address in tracepoint.c
      More use of block_symbol::address in tracepoint.c
      Use block_symbol::address in ax-gdb.c
      Use block_symbol::address in linespec.c
      Use block_symbol::address in ada-lang.c
      Use block_symbol::address in symmisc.c
      Introduce read_var_value overload
      Use read_var_value in gdb/compile
      Return a block_symbol from find_pc_sect_function
      Use read_var_value overload in finish_command_fsm
      Use block_symbol in overload-handling code
      Change evaluate_var_value to accept a block_symbol
      Change value_of_variable to take a block_symbol
      Return a block_symbol from get_frame_function
      Use read_var_value overload in return_command
      Use read_var_value overload in py-finishbreakpoint.c
      Use read_var_value overload in py-framefilter.c
      Use read_var_value overload in Guile
      Use read_var_value in read_frame_arg and read_frame_local
      Change print_variable_and_value to take a block_symbol
      Change find_frame_funname to return a block_symbol
      Change btrace_function::sym to a block_symbol
      Use read_var_value overload in Python
      Remove the old read_var_value
      Change language_defn::read_var_value to accept block_symbol

 gdb/ada-lang.c                      |  51 +++++++------
 gdb/ada-tasks.c                     |  14 ++--
 gdb/ax-gdb.c                        |  28 +++----
 gdb/ax-gdb.h                        |   2 +-
 gdb/block-symbol.h                  |  41 +++++++++++
 gdb/blockframe.c                    |  18 ++---
 gdb/breakpoint.c                    |   4 +-
 gdb/btrace.c                        |  38 +++++-----
 gdb/btrace.h                        |   5 +-
 gdb/cli/cli-cmds.c                  |   4 +-
 gdb/compile/compile-c-symbols.c     |  18 +++--
 gdb/compile/compile-cplus-symbols.c |   6 +-
 gdb/compile/compile-cplus-types.c   |   2 +-
 gdb/compile/compile-loc2c.c         |  14 ++--
 gdb/compile/compile.h               |   6 +-
 gdb/cp-support.c                    |  46 +++++++-----
 gdb/cp-support.h                    |   6 +-
 gdb/dwarf2/ada-imported.c           |   2 +-
 gdb/dwarf2/loc.c                    |  16 ++--
 gdb/dwarf2/loc.h                    |   3 +-
 gdb/eval.c                          |  62 +++++++---------
 gdb/expop.h                         |   5 ++
 gdb/f-valprint.c                    |   4 +-
 gdb/findvar.c                       |  24 +++---
 gdb/frame.c                         |   2 +-
 gdb/frame.h                         |   9 ++-
 gdb/guile/guile-internal.h          |   2 +-
 gdb/guile/scm-block.c               |   6 +-
 gdb/guile/scm-frame.c               |   7 +-
 gdb/guile/scm-symbol.c              |  78 ++++++++++----------
 gdb/infcall.c                       |   4 +-
 gdb/infcmd.c                        |  29 ++++----
 gdb/infrun.c                        |  10 +--
 gdb/inline-frame.c                  |   2 +-
 gdb/language.h                      |  14 +---
 gdb/linespec.c                      |  15 ++--
 gdb/mi/mi-cmd-stack.c               |  20 ++---
 gdb/printcmd.c                      |  21 +++---
 gdb/python/py-block.c               |   6 +-
 gdb/python/py-finishbreakpoint.c    |  11 +--
 gdb/python/py-frame.c               |  15 ++--
 gdb/python/py-framefilter.c         |  64 +++++++---------
 gdb/python/py-objfile.c             |  16 ++--
 gdb/python/py-record-btrace.c       |   2 +-
 gdb/python/py-symbol.c              | 143 ++++++++++++++++++------------------
 gdb/python/py-type.c                |   2 +-
 gdb/python/py-unwind.c              |   4 +-
 gdb/python/python-internal.h        |   4 +-
 gdb/record-btrace.c                 |   8 +-
 gdb/rust-lang.c                     |   2 +-
 gdb/skip.c                          |   2 +-
 gdb/solib-frv.c                     |   2 +-
 gdb/sparc-tdep.c                    |   4 +-
 gdb/stack.c                         |  59 ++++++++-------
 gdb/stack.h                         |   2 +-
 gdb/symmisc.c                       |  15 ++--
 gdb/symtab.c                        |   4 +-
 gdb/symtab.h                        |  22 ++----
 gdb/tracepoint.c                    |  24 +++---
 gdb/tracepoint.h                    |   2 +-
 gdb/valarith.c                      |   9 +--
 gdb/valops.c                        |  75 ++++++++++---------
 gdb/value.c                         |   2 +-
 gdb/value.h                         |  18 ++---
 64 files changed, 597 insertions(+), 558 deletions(-)
---
base-commit: 04f0f42bcf4fb5f7bbde0b954f816c5f6ff7f571
change-id: 20231029-split-objfile-2023-bound-sym-october-8da7ff1061cc

Best regards,
  

On 2023-10-29 19:23, Tom Tromey wrote:
> Every year or so, I take a stab at the objfile splitting work.  This
> always fails and I end up not sending anything.
> 
> This year, I decided to take a baby step instead, thinking maybe it
> would be possible to slowly grind away at the problem.
> 
> This series is the first such step.  It spreads the use of
> block_symbol through a bunch of code, trying to eliminate calls to
> symbol::value_address.
> 
> The longer term idea here is to then add an objfile member to
> block_symbol.  After this, it would be relatively simple to change
> symbols to be relocated at point of use.  (This would be a significant
> step toward objfile splitting, but there's even more to do after
> that...)

I started to read this series, and I don't quite grasp why it's useful
to expand the use of the block_symbol structure specifically.  If a
function returns or accepts a struct symbol today, once the struct
symbol is made objfile-independent, that function will then need to
return or accept a bound_symbol structure (which does not exist yet)
containing a a symbol and an objfile (just like bound_minimal_symbol).
But I don't see why the block comes into play.  Presumably, a function
that doesn't care about the block today won't care about the block
after.  Am I missing something?  I'm not so familiar with the
symbol-related code.

Simon
  

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

>> The longer term idea here is to then add an objfile member to
>> block_symbol.  After this, it would be relatively simple to change
>> symbols to be relocated at point of use.  (This would be a significant
>> step toward objfile splitting, but there's even more to do after
>> that...)

Simon> I started to read this series, and I don't quite grasp why it's useful
Simon> to expand the use of the block_symbol structure specifically.  If a
Simon> function returns or accepts a struct symbol today, once the struct
Simon> symbol is made objfile-independent, that function will then need to
Simon> return or accept a bound_symbol structure (which does not exist yet)
Simon> containing a a symbol and an objfile (just like bound_minimal_symbol).
Simon> But I don't see why the block comes into play.  Presumably, a function
Simon> that doesn't care about the block today won't care about the block
Simon> after.  Am I missing something?  I'm not so familiar with the
Simon> symbol-related code.

I went through the series again.  I found a couple of spots where a
bound_symbol would be good to have, so v2 will include that change.

Overall, though, I think block_symbol is probably ok in this series.
It's maybe not the absolute ideal, but on the other hand it's relatively
harmless to use, and in a lot of places it is convenient.

The main thing that makes it ok, IMO, is that symbol lookup has to
return a block_symbol because the parsers want to track the smallest
enclosing block.  This choice then spreads through the code a bit.

Also, read_var_value sort of "wants" to take a block_symbol.
Historically you could pass NULL as the block, but this lead to
confusion in some places, plus some arguable bug -- e.g., how symbol
value computation is handled in Python.  Making this change, again IMO,
improves the code by removing something to think about.

When I say this isn't the ideal, I guess if I was writing all this from
scratch, I'd probably just give a symbol a backlink to its block, and
then have blocks link to the symtab somehow.  But then there are a dozen
things I'd do differently, because the way symbols are done in gdb is
bad.

Unlike the case with minsyms (or psyms or line tables), splitting
symbols in gdb can't really be done all at once.  IMO.  There are just
too many things to touch.  There's a reasonably complete list on the
wiki.

If you do read through the series and find a spot you think would be
better off using bound_symbol, let me know and I'll make the change.  In
my search I found the tracepoint.c patch and the symmisc.c patch.  But
maybe there are others, it's sometimes hard to tell.

Tom