tree 8e9f4171e354b94f2ca674a598531152d2920a62
parent b9de07a5ff74663ff39bf03632d1b2ea417bf8d5
author Bernd Edlinger <bernd.edlinger@hotmail.de> 1729012452 +0100
committer Andrew Burgess <aburgess@redhat.com> 1731505821 +0000

gdb: stepping between inline functions with multiple ranges

I (Andrew) have split this small change from a larger patch which was
posted here:

  https://inbox.sourceware.org/gdb-patches/AS1PR01MB9465608EBD5D62642C51C428E4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com

And I have written the stand alone test for this issue.  The original
patch included this paragraph to explain this change (I've fixed one
typo in this text replacing 'program' with 'function'):

  ... it may happen that the infrun machinery steps from one inline
  range to another inline range of the same inline function.  That can
  look like jumping back and forth from the calling function to the
  inline function, while really the inline function just jumps from a
  hot to a cold section of the code, i.e. error handling.

The important thing that happens here is that both the outer function
and the inline function must both have multiple ranges.  When the
inferior is within the inline function and moves from one range to
another it is critical that the address we stop at is the start of a
range in both the outer function and the inline function.

The diagram below represents how the functions are split and aligned:

                           (A)       (B)
  bar:         |------------|         |---|
  foo:   |------------------|         |--------|

The inferior is stepping through 'bar' and eventually reaches
point (A) at which point control passes to point (B).

Currently, when the inferior stops, GDB notices that both 'foo' and
'bar' start at address (B), and so GDB uses the inline frame mechanism
to skip 'bar' and tells the user that the inferior is in 'foo'.

However, as we were in 'bar' before the step then it makes sense that
we should be in 'bar' after the step, and this is what the patch does.

There are two tests using the DWARF assembler, the first checks the
above situation and ensures that GDB reports 'bar' after the step.

The second test is similar, but after the step we enter a new range
where a different inline function starts, something like this:

                           (A)       (B)
  bar:         |------------|
  baz:                                |---|
  foo:   |------------------|         |--------|

In this case as we step at (A) and land at (B) we leave 'bar' and
expect to stop in 'foo', GDB shouldn't automatically enter 'baz' as
that is a completely different inline function.  And this is, indeed,
what we see.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>