[Valgrind-developers] A dwarf call-frame question

[Julian S. <js...@ac...>]

Tom

Someone recently sent me a libcrypto.so.0.9.8 as distributed with Ubuntu
of some flavour, compiled with gcc 4.1.2 on amd64.  It causes V's CF reader
to complain a lot:

>> --19976-- DWARF2 CFI reader: unhandled CFI instruction 0:24
>> --19976-- DWARF2 CFI reader: unhandled CFI instruction 0:24
>> --19976-- DWARF2 CFI reader: unhandled CFI instruction 0:24
>> --19976-- DWARF2 CFI reader: unhandled CFI instruction 0:24
>> --19976-- DWARF2 CFI reader: unhandled CFI instruction 0:48
>> --19976-- DWARF2 CFI reader: unhandled CFI instruction 0:24

After chasing this around a bit it seems that the CF bytecode
parser lost sync at a DW_CFA_set_loc, which has a single argument
denoting an address.

As it stands that address is extracted by read_Addr() (readdwarf.c
line 1730 approx).  On amd64 that just fetches 8 bytes regardless
of anything else.

I noticed also read_encoded_Addr() which looks altogether more
sophisticated -- I presume it's something you added.  This appears
to take into account some kind of encoding flag.  When I replace
the uses of read_Addr by read_encoded_Addr for DW_CFA_set_loc,
the complaints go away, there is no loss of sync, and the parsed
CF instructions are the same as shown by readelf --debug-dump=frames.

So it seems a plausible fix.  The problem is I looked in the DWARF3
spec and completely failed to figure out whether or not the arg to
DW_CFA_set_loc is supposed to be encoded in a way suitable for
read_encoded_Addr, nor for that matter any description of what it is
that read_encoded_Addr is really decoding.  But then I've never been
good at navigating the DWARF3 spec.

Any idea if this is the right fix?  I can send the .so + test prog
+ my current ugly patch if you like.

J