DWARF Standard


HOME
SPECIFICATIONS
FAQ
ISSUES



040729.1 David Anderson Outermost Frame Identification Extension Accepted revised proposal Todd Allen


Andrew Cagney asked:
> When unwinding, is there a way to detect that the outer-most-frame has
> been reached (for a typical program that is _start)?

> Using this as an example, is there an abi independant way of identifying
> the outermost (or oldest) stack frame, namely __thread_boot?  (The
> question of which of these frames should be displayed when the user does 
> a backtrace is important but orthogonal.)
> 
> As I noted: If nothing else, having the CFI return-address "undefined"
> (and also the CFA) would make the intent very clear :-)
And, speaking of special cases:
>In both cases the markup could be "unknown" CFA/RA.

 Chris Quenelle  added:
>A compiler flag is still the only way that I can think of
>to mark these functions.  The compiler can't tell by itself
>which ones need to be marked.

James Cownie  wrote:

>Having the run time libraries describe what they're doing to the
>debugger avoids an unnecessary tight compatiblity linkage between the
>two components, and that is _good_.

Andrew Cagney wrote :-
> (1) It can't be zero as that creates a catch-22 for the debugger - can't
> differentiate between a backtrace through a NULL pointer call, and a
> bottom of stack.

James Cownie added:

Note also that on machines with a signed address space (some of which
may be gdb targets) zero is a valid address in the middle of the address
space. (The Inmos "transputer" was like this, and though they don't exist
as separate chips anymore they're still used as an embedded core; if you
have a set-top box you may well own one ;-)

David Anderson:

Adding an attribute to a function DIE would be a suitable marking,
but would not help if .debug_info was missing but .debug_frame
was present.

One could imagine adding a new FDE field, a flag,
after 'address_range' field and before 'instructions' field of the FDE
(requiring a version change of .debug_frame).

A new call frame instruction, such as
DW_CFA_no_unwind
could signal that no unwind is appropriate.


PROPOSAL:

Add a new Call Frame Instruction to 6.4.2:
	DW_CFA_no_unwind
which would usually be the only CFI for the function (normally
not mixed in with other Call Frame Instructions for a frame).

24: DW_CFA_no_unwind
The DW_CFA_no_unwind instruction takes no operands. It indicates
that this frame should not be unwound, there is no calling frame.
Normally this would be the only instruction for this FDE.

In italics:
Which functions cannot-be-unwound from, such as thread-start
routine code or process-start code, is known to the
builders of that special code and would be communicated to a compiler/assembler
via compiler flags or pragmas.


=========================================

Revised proposal:
Append to 6.4.4 Call Frame Calling Address:

   If a Return Address register is defined in the virtual unwind table, and
   its rule is undefined (e.g. via DW_CFA_undefined), then typically there is
   no return address and no call address, and the virtual unwind of the stack
   activiations is complete.

Accepted, removing word "typically".


All logos and trademarks in this site are property of their respective owner.
The comments are property of their posters, all the rest © 2007-2017 by DWARF Standards Committee.