Kaz Kylheku wrote:
> Hi Everyone,
>
> I don't have a lot of detailed information about this bug; it comes to
> me second hand. I don't have a minimal test case to reproduce it (I
> eventually will). But I was wondering whether anyone has seen anything
> like this.
>
> The generated code for a C++ class member function saves the gp
> register on the stack. Smack in the middle, it suddenly decides to
> restore the value of that register from the stack. After that, a
> shared library call fails (gp is used to hold the base addresses of
> global offset tables). The gp points to the wrong GOT.
>
> Making some trivial perturbation in the source code makes the problem
> go away. The change is alon the lines of uncommenting a function call
> like this:
>
> void Foo::Bar()
> {
> /* ... */
>
> // uncomment the following, problem goes away.
> // int notused = memberPointer->inlineFunction();
>
> if (somecondition() || memberPointer->inlineFunction() != FOO) ...
>
> Very strange.
>
> Sorry to post crap like this with no useful information, but it was
> reported to me late Friday evening just before going home. :)
>
> My question is, under what conditions would the compiler ever want to
> restore the caller's value for the global offset pointer and actually
> use it, rather than just restore it before returning to the caller?
None that I can think of.
Unless you want to fix it your self, a self contained test case logged
to http://gcc.gnu.org/bugzilla/ is the best bet for getting the problem
solved. Alternately try 4.2 or 4.3.
David Daney
