[Dwarf-Discuss] Location list entries for caller-saved registers at time of call

[Cary Coutant]

> > In fact, the PA-RISC and Itanium calling conventions specifically require this.
>
> Not all ABIs do this.  Many allow the end of one function to be
> immediately followed by the start of the next function.

We're talking about the narrow case of a function that ends with a
no-return call. In all other situations, of course it's fine to have
one function immediately follow the previous.

This also applies to no-return calls in the interior of a function,
where the next instruction might be part of a code region with
different unwind descriptors.

> Subtracting one from the return address is a trivial way to insure
> that the address is within the calling function and not in the
> next function.  And it works on all architectures.

It's not exactly trivial: it's not always correct to do this (e.g.,
when unwinding from a signal handler), and the unwinder needs to know
how to recognize those kinds of frames. For PA-RISC and Itanium, we
elected to make the rule simple: the pc value, whether it derives from
a return pointer or a sigcontext, will always get you the correct
unwind information.

But we're getting sidetracked from the OP's question: Does GCC in fact
subtract one from the upper bound of a location list entry for a
variable contained in a caller-saved register? I can think of no
reason why it should do this. If the compiled code does something like
this:

    A: promote variable X into caller-save register R
       ...
       call f
    B: ...
       spill register R back to X
    C: ...

The location list entry for x should show it live in register R in the
range [A..C). The call should not interrupt the range.

It sounds like David has an example where the range list entry shows x
in register R in the range [A..B-1), then presumably again for [B..C),
leaving [B-1..B) uncovered. That would be a bug, in my opinion.

David, can you show us an example?

-cary

-cary