On Fri, Jan 15, 2016 at 3:33 AM, Armin Rigo <ar...@tunes.org> wrote: > Hi Richard, > > On Thu, Jan 14, 2016 at 6:32 PM, Richard Plangger <planri...@gmail.com> wrote: >> <trace call> -- parameter (1213,1213) both 64-bit >> <calls the python function that returns 1213+1213 = 2426 >> as 64bit integer> (2) > > Do you mean in both cases 16-bit integer instead of 64-bit integer? > >> returns every frame back to <trace call> and saves 0xdeadbeefdead097a > >> My understanding is that: libffi expects that <trace call> should, just >> after returning the 64 bit value, cast the result to a 16 bit value. >> We cannot do that! > > If I understand correctly, you can do exactly that. After a call > instruction to a function that returns a 16 bits result, simply add > another instruction to sign- or zero-extend the result to a full > 64-bit value. Surely it is not a performance problem to add a > single simple instruction after some rare calls? > > In more details: my point of view is that libffi is *documented* to > return the value > 0x000000000000097a, but instead it returns 0xdeadbeefdead097a. It's a > bug in libffi, but maybe one that is not going to be fixed promptly. > In that case, you can simply work around it. Specifically, > after a "call_i" instruction that should return a 16-bit number: the > official ABI says it should return 0x000000000000097a; when called via > ctypes it returns 0xdeadbeefdead097a instead; so go for the careful > solution and only assume that the last 16 bits are valid, and emit an > instruction just after the call to sign- or zero-extend the result > from 16 bits to 64 bits. Then you can leave the issue in the hands of > libffi for s390x and not be annoyed if it doesn't get fixed.
libffi is *documented* to return the non sign-extended value. - David _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
