Topic
  • 1 reply
  • Latest Post - ‏2011-03-09T00:09:59Z by Kiefer.Fender
jpiaget
jpiaget
2 Posts

Pinned topic toc overflow code does not restore toc upon return from routine

‏2010-08-03T17:34:54Z |
I am debugging a coredump where it looks like the $r2 variable has an unusual value. Tracing program low in dbx, I see that we reach the end of a particular routine (foo) , restore all general-purpose registers, then branch (not branch-link) to __restf15, which is supposed to restore all FP registers 15 through 31.

Instead of going directly to __restf15, the program flow goes through some code that does a bunch of consecutive branches, then reaches a routine which save $r2 and replaces it with a new value and does a bctr to __restf15. __restf15 does exactly what is expected (restores FP registers 15 to 31), then does a blr, which returns control back to the routine that called the original (foo) routine. $r2 was never restored.

When the application was compiled, we see a message saying there is a TOC overflow. When I saw the program flow described above, it looks like this is code that swaps out the TOC in an overflow case ... but for whatever reason, does not restore it

I am not sure if this is a bug, a linking issue, or what. There are several instances of __restf15 in the application. If we were able to restrict the set of __restf15 that might be called, that could avoid the problem ... but I'm not sure this would really be a fix.

Has anyone hit this problem or might understand how this could happen with various parts of the application compiled in different ways?

Thanks,
Jeff Piaget
Updated on 2011-03-09T00:09:59Z at 2011-03-09T00:09:59Z by Kiefer.Fender
  • Kiefer.Fender
    Kiefer.Fender
    1 Post

    Re: toc overflow code does not restore toc upon return from routine

    ‏2011-03-09T00:09:59Z  
    jpiaget wrote:
    I am debugging a coredump where it looks like the $r2 variable has an unusual value. Tracing program low in dbx, I see that we reach the end of a particular routine (foo) , restore all general-purpose registers, then branch (not branch-link) to __restf15, which is supposed to restore all FP registers 15 through 31.

    Instead of going directly to __restf15, the program flow goes through some code that does a bunch of consecutive branches, then reaches a routine which save $r2 and replaces it with a new value and does a bctr to __restf15. __restf15 does exactly what is expected (restores FP registers 15 to 31), then does a blr, which returns control back to the routine that called the original (foo) routine. $r2 was never restored.

    When the application was compiled, we see a message saying there is a TOC overflow. When I saw the program flow described above, it looks like this is code that swaps out the TOC in an overflow case ... but for whatever reason, does not restore it

    I am not sure if this is a bug, a linking issue, or what. There are several instances of __restf15 in the application. If we were able to restrict the set of __restf15 that might be called, that could avoid the problem ... but I'm not sure this would really be a fix.

    Has anyone hit this problem or might understand how this could happen with various parts of the application compiled in different ways?

    Thanks,
    Jeff Piaget

    Anybody can help? I've got the same problem, I've been waiting for the answer, Could you give more details?