Hi, (Could I ask to get a CC of answers via mail? I am not subscribed to this list.)
Thank you for your response! Bastian Blank wrote: > On Tue, Jun 13, 2017 at 09:38:44AM +0200, Ole Streicher wrote: >> I am slowly re-starting the packaging of IRAF (still not officially >> announced yet). When porting to s390x, I however run into a strange >> error: IRAF needs a small piece of assembler code (kind-of longjump for >> Fortan), which John Long gratefully ported to s390x two years ago: > > Is IRAF the stuff from http://iraf.noao.edu/ and last released five > years ago? Yes. I could convince upstream to put it into a git repository, <https://github.com/iraf/iraf-v216> and now I am creating pull requests to get it more Debian friendly: portability, build from the tarball, removal of oddly licensed code. To port zsvjmp, I created a small project three years ago: <https://github.com/olebole/zsvjmp>. >> zsvjmp_: [...] >> j __sigsetjmp@PLT > > Looks like it is, but why do you want this jump via the PLT, while all > other variants do not? > > | ./unix/as.linux/zsvjmp.s: jmp __sigsetjmp # let > sigsetjmp do the rest > | ./unix/as.linux64/zsvjmp_c:asm(" jmp __sigsetjmp # let > sigsetjmp do the rest"); That is way outdated. At least for x86_64, I need the @PLT now to avoid linker errors. From my (very limited) understanding, @PLT would be correct, since sigsetjmp resides in a shared lib (libc). >> Could anyone help me here what is wrong with that assembler? > > To make this work, you need to build with -fPIC. This didn't help, I still get the same error message. Since zsvjmp.o will be statically linked (yet), I also don't see why -fPIC would be needed. >From browsing the S390 mnemonic list, I tried to replace the "j" opcode with a "jg", and then the compilation succeeds. However, this is a very wild guess, since the menmonic list just in both cases said it were a "jump". Can you (or someone) confirm that "jg" is correct here? The code still does not work, and I want to be sure that "jg" is not causing this. Best regards Ole
