Hi, My previous attempt wasn't of much help, I presume ;-)
I redid a few things with a fresh head today; I had a look at the code as it occurs with -O2, and ran it one opcode at a time in the problematic function, checkXmlEqual. I found the following: The function checkXmlEqual seems to be optimized to preload function addresses into address registers, so that performing a function call into a library isn't as expensive as looking up the address in the PLT section every time a function is called. It does that for three functions: 0x8004e95a lea 0x8004dc70 <XmlUniformiser>,%a4 [...] 0x8004e96a lea 0x8004e6f0 <_ZN14XmlUniformiser8strippedEv>,%a3 [...] 0x8004e978 lea 0x80006020 <[EMAIL PROTECTED]>,%a5 [...] Later on, it can then easily jump to those functions by calling jsr %a5@ or so, which is faster than explicitely adding the address as an operand. However, this only works under the assumption that no function called by checkXmlEqual modifies those registers; and this seems to be an incorrect assumption... Watchpoint 7: $a5 Old value = (void *) 0x80006020 New value = (void *) 0xc012bbcc 0xc00e7c54 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string () from /usr/lib/libstdc++.so.6 (gdb) A stack trace shows this is at 0x8004e9a6, which is a call to... 0x8004e9a6 jsr %a5@ ... right. Presumably that function should also store the registers on the stack, and restore them afterwards. This sounds like an optimizer bug to me, but I'm not too comfortable with this type of bughunting yet... anyone? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
