On 21/09/11 22:05, Wickham, Mark wrote: > The problem is that the symbols are packed, and therefore some of the items > are misaligned and on ARM, that typically causes a fault, but on this > processor it is reading incorrect values from misaligned addresses. For > example, a 32-bit read at an odd address results in a totally bogus value.
Oh sure, doing unaligned reads on an ARM that isn't in strict alignment mode will get what appear to be undefined values. They are actually well defined, they're just not what you would expect unless you'd been reading the processor manual... > I think replacing all of the *(UShort *) and *(UInt *) and *(ULong *) > expressions in coregrind/m_debuginfo/readdwarf.c with read_UShort() and > friends would solve the problem. I was able to verify that it works better > if I use this function for the version number reading - now I get DWARF > version 2, instead of 512 or 1024. Sounds like it, yes. Can you open a bug with this information on it please. Tom -- Tom Hughes ([email protected]) http://compton.nu/ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
