[Dwarf-Discuss] DW_OP_call* referencing DIE without DW_AT_location

[David Anderson]

On 10/01/2010 12:49 PM, Jakub Jelinek wrote:
> Hi!
>
> What is the rationale for specifying that DW_OP_call* to
> DIE without DW_AT_location acts like DW_OP_nop?  It doesn't make
> much sense to emit the DW_OP_call* in that case.
>
> We would see a use for a different behavior, though of course
> another possibility is to add yet another DW_OP_* opcode.
>
> The problem we are trying to solve are addresses of external symbols.
> Say on:
>
> extern int foo, bar;
> int fn1 (void)
> {
>    int *p =&foo;
>    fn2 (0);
>    p =&bar;
>    fn2 (1);
>    return 0;
> }
>
> we don't want to emit DW_OP_addr<foo>  and DW_OP_addr<bar>  in .debug_loc
> for p, because
> 1) we want code compiled with debug info to behave the same as the same code
>     compiled without debug info.  In the above, when all references to foo
>     and bar are optimized away in real code, having them left only in
>     .debug_* sections would mean -g compiled code wouldn't link if there
>     is no foo or bar definition, while -g0 code would link fine
> 2) our linker doesn't create relocation sections for binaries or
>     shared libraries against .debug_* sections, relocations are there only
>     for object files and are resolved during linking; the debugger
>     just uses the DWARF forms etc. to find out what needs to be relocated
>     by the shared library load bias and what should be kept.

DW_OP_call*  operators were introduced in DWARF3.   It strikes me as 
extremely
unlikely we would, at this late date, change the semantics.     We 
usually resist
such changes quite strongly.

I find nothing in the closed-issues about these ops,  nor any other 
written info
on the topic.   Unfortunately.    Nor do I recall the specific 
discussions of these.

Things in DWARF4 (DW_FORM_ref_addr) have implied the necessity
of relocations preserved for .debug_* sections.  Relocations the 
debugger must
apply at debug time.  It is your choice whether or not to support those 
sorts of relocations.

Your issue 1) is also a linker issue (not really a DWARF issue).  If I 
read it correctly.

At any rate, I rather think  a semantics change in DWARF is not a 
suitable approach
to solve your problem.  I'm sure you will find a solution :-)

David Anderson