This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: VTA merge - introduction


>> Ah. ?Well, it could if we dropped the constant into memory, like I think
>> we do for some other debugging constants.
>
> I'm pretty sure we did, and that this caused bootstrap-debug failures
> very early on. ?We could get debug info to refer to a constant in
> non-debug memory if we found it to be already there. ?Failing that, we
> could perhaps emit the constant into debug memory, but I'm not sure how
> debug info consumers would cope with locations in debug sections.

I see no reason to bother with this. As soon as we get values assigned
for DW_OP_stack_value (for integral-type expressions) and
DW_OP_implicit_value (for constant fp and aggregate values), you
should be able to go ahead and use them. I'm checking with the editor
of the DWARF spec, and I'm hoping he can confirm the final values
shortly. The latest draft shows these values, which I expect will
stick:

  DW_OP_implicit_value 0x9e
  DW_OP_stack_value 0x9f

Since they're just upward-compatible DWARF extensions, I don't think
you should even gate them on the (not yet mainline) -gdwarf-4 option.
I suspect that an unmodified gdb will choke upon seeing these opcodes,
but the breakage should be limited to ranges where you otherwise
wouldn't have had a location expression for it anyway.

-cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]