Bug#340563: Optimizer bug, presumably.
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 <_ZNSsD1Ev@plt>,%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?
--
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
Reply to: