[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
From:       Ulrich Weigand via KDE Bugzilla <bugzilla_noreply () kde ! org>
Date:       2016-09-26 15:57:50
Message-ID: bug-369175-17878-JapjllL5DM () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=369175

Ulrich Weigand <uweigand@de.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uweigand@de.ibm.com

--- Comment #23 from Ulrich Weigand <uweigand@de.ibm.com> ---
Will asked me to look at this bug and comment from the perspective of the Power
ABI ...

Now, with the ppc64(be) (or AIX) ABI, to call a function via function pointer
you need to do two things:
- read the target functions' TOC pointer from the function descriptor (word 1)
and load it into r2, *and*
- read the target functions' entry point address from the function descriptor
(word 0) and transfer control to it

(And of course you need to save the old value of r2 before the call and restore
it afterwards.  To be fully correct, you also need to load the static chain
pointer from word 2 of the function descriptor and load it into r11 -- but that
only matters when calling a nested function.)

If you're jumping into a function descriptor (as in comment #19), then you're
clearly treating a function descriptor address as if it were an entry point
address, which is of course wrong.

However, adding calls to fnptr_to_fnentry at a high level likewise seems wrong,
since once you've done that, you've forgotten where the function descriptor was
and have no chance of then retrieving the correct TOC value to load into r2
before the call.  And in fact, the crash in comment #7 seems a typical example
of what happens when calling a function without setting up its TOC pointer
correctly.

I'm not very familiar with valgrind internals, but what I'd have expected to
happen is that the function pointer value (i.e. function descriptor address) is
being kept around in the IR until that (platform-specific) point where actual
function call instructions (bctrl etc.) are emitted; and only at *that* point
look into the function descriptor and use it to load both TOC pointer and entry
point address.

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]