On Wed, Jul 13, 2011 at 01:36:03PM -0600, Tom Tromey wrote:
> I wrote a gdb patch for this. I've appended it in case you want to try
> it out; it is against git master. I tried it a little on an executable
> Jakub sent me and it seems to work fine.
Thanks.
> It is no trouble to change this patch if you change the format. It
> wasn't hard to write in the first place, it just bigger than it is
> because I moved a bunch of code into a new function.
>
> I don't think I really understood DW_MACINFO_GNU_define_opcode, so the
> implementation here is probably wrong.
Well, I think you've skipped it correctly and furthermore even patched
GCC doesn't emit it. The point of it was to allow skipping unknown
opcodes. If you implement this opcode fully and say GCC 4.8 adds a new
vendor opcode, the old implementation would be able to silently skip
over such opcodes.
So, the reader implementation could do something like have an array
of 256 pointers, at the start of parsing a particular .debug_macinfo
chunk clear it (or, when the chunk is read because of
DW_MACINFO_GNU_transparent_include4 it would instead make a copy
of the current array and make the copy current), and when you encounter
DW_OP_GNU_define_opcode, you store a pointer to the encoded operands
of that opcode into the table. And, when you find an unknown opcode
(reach default: case), and array[op] is non-NULL, you read the uleb128
from that location to get the count and iterate over the DW_FORM_* values
in the array and for each of them skip corresponding bytes from the opcode's
operand. Say .debug_macinfo chunk could start with
DW_MACINFO_GNU_define_opcode, 0xe5, 2, DW_FORM_udata, DW_FORM_block,
DW_MACINFO_define, 0, "A 1",
0xe5, 0x80, 0x7f, 5, 1, 2, 3, 4, 5,
DW_MACINFO_define, 0, "B 1",
0
and you'd be able to grok both defines in it, because you'd understand
that after seeing 0xe5 you need to read one uleb128, another uleb128 and
skip the second number of bytes after it.
The copy of the table would be so that the producer could define_opcode just
in the .debug_macinfo spot referenced from DW_AT_macro_info and wouldn't
have to repeat it in the transparent include chains, if it ensured that the
chains wouldn't be merged without having the define_opcode in all the
referencing .debug_macinfo sections. And the copy of array allows the
transparent chain to add new opcodes or redefine them, while not affecting
the outer sequence.
Jakub
