------- Comment #22 from jakub at gcc dot gnu dot org 2009-09-21 08:40 -------
Created an attachment (id=18620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18620&action=view)
gcc45-pr41404.patch
This fixes the bug, unfortunately doesn't do any good with CONST_STRINGs.
CONST_STRING as emitted by expand_debug_expr is the address of the string
literal, (mem:BLK (const_string "foobar")) is the string itself. And, for
address of the constant string, we really have to give an address in the
address space of the process, not a relative address of a .debug_str section
entry.
But, if the string has been already added to .rodata/.rodata.str*,
lookup_constant_def will already succeed. Some testcases:
__attribute__((noinline))
int bar (void)
{
const char *foo = "foo";
asm volatile ("nop" : : : "memory");
foo = "bar";
asm volatile ("nop" : : : "memory");
return 16;
}
int main (void)
{
bar ();
return 0;
}
In the above we are out of luck, neither of the strings is in .rodata.
const char *baz (int i)
{
return i ? "foo" : "bar";
}
__attribute__((noinline))
int bar (void)
{
const char *foo = "foo";
asm volatile ("nop" : : : "memory");
foo = "bar";
asm volatile ("nop" : : : "memory");
return 16;
}
int main (void)
{
bar ();
return 0;
}
Here it is handled right already without this patch, lookup_constant_def
returns non-NULL_RTX in expand_debug_rtx. But if bar and baz are swapped:
__attribute__((noinline))
int bar (void)
{
const char *foo = "foo";
asm volatile ("nop" : : : "memory");
foo = "bar";
asm volatile ("nop" : : : "memory");
return 16;
}
const char *baz (int i)
{
return i ? "foo" : "bar";
}
int main (void)
{
bar ();
return 0;
}
then even lookup_constant_def in dwarf2out will fail. We'd have to defer this
lookup until and of compilation, before debug info is sized and emitted into
assembly, call lookup_constant_def again and if it succeeds, output it as
DW_OP_implicit_value .LCXX, if not, say that it is not available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
