> > 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
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
