[Dwarf-Discuss] DW_OP_call* referencing DIE without
Bishop, John E
john.e.bishop at intel.com
Tue Oct 5 10:50:09 PDT 2010
Given this code:
extern int foo, bar;
int fn1 (void)
int *p = &foo;
p = &bar;
The initial author expected the DWARF for "p" to include a location
of "DW_OP_addr <foo>". If "foo" were optimized away, then the DWARF
could not be linked because it would reference a name that didn't
have an address.
1. There seems to be an assumption that "p" has no storage and thus
the DWARF for it is just the value.
To me it looks like the DW_AT_location for "p" should be an address
or register holding the value of "p".
If "p" is optimized away, then the DWARF can have just the variable
"p" without a DW_AT_Location and the normal response works fine.
2. If you want to give a value for "p", then the scheme proposed might
work for unoptimized code. If the compiler removes "foo", then when
the compiler goes to issue the DWARF for "p" it should know that it
can't give a value, so it won't issue those records, so where's the problem?
3. The comment about search sequences surprises me -- under what circumstances
is a shared library going to be searched before the current compilation
Isn't the search order of "other .o files" before "shared libraries"
anyway. So the issue only arises if the external reference to "foo"
stays and the definition goes.
The compiler is in charge in both cases: it can either not put
in the external ref or if "-g" is on it can leave a dummy definition
for "foo" when optimized away.
4. Finally, if "foo" is optimized away in a different .o file, isn't
that a languageerror which shows up at link time? This code claims
that "foo" exists and has an address. It doesn't, therefore it's
a coding error.
I feel I'm missing something as this discussion doesn't seem have a
debugging problem to work on.
If "foo" is not local to the current compilation unit, then if there
is a "foo" in a shared library as well as somewhere else, then ther
f you have a "
More information about the Dwarf-Discuss