|
From: Julian S. <js...@ac...> - 2006-11-15 13:18:55
|
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 |