<div dir="ltr"><div><div><div><div><div>Hello,<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_121704980726567103gmail-im">
</span>Would that only be applicable to 32-bit?<br>
To familiarise myself with these concepts I found this a good<br>
explanation of Position Independent Code...<br>
* <a href="http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries" rel="noreferrer" target="_blank">http://eli.thegreenplace.net/2<wbr>011/11/03/position-independent<wbr>-code-pic-in-shared-libraries</a><br>
which says it "... will explain only how PIC works on x86, picking<br>
this older architecture specifically because (unlike x64) it wasn't<br>
designed with PIC in mind, so implementing PIC on it is a bit trickier<br>
... Some non-Intel architectures like SPARC64 force PIC-only code for<br>
shared libraries, and many others (for example, ARM) include<br>
IP-relative addressing modes to make PIC more efficient. Both are true<br>
for the successor of x86, the x64 architecture."<br>
<br>
and the sister article on Load Time Relocation...<br>
* <a href="http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/" rel="noreferrer" target="_blank">http://eli.thegreenplace.net/2<wbr>011/08/25/load-time-relocation<wbr>-of-shared-libraries/</a><br>
says "... some modern systems (such as x86-64) no longer support<br>
load-time relocation."<br>
<br>
and at the bottom here describes why -nopic on 64-bit requires -mcmodel=large.<br>
* <a href="http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64" rel="noreferrer" target="_blank">http://eli.thegreenplace.net/2<wbr>011/11/11/position-independent<wbr>-code-pic-in-shared-libraries-<wbr>on-x64</a></blockquote><div>Perphaps. I have not tested the 64 bits Linux without forcing -fno-pie and -no-pie on my build. The default option on Ubuntu 16.10 is not -fPIC, but -fpie which is to allow Address Space Layout Randomization (a technique to mitigate security exploits based on buffer overflows, and return oriented programming) of the code of the executables themselves. The executables, unlike shared libraries usually are not compiled as position independent code even on x86_64. On x86_64, the difference on PIC/no PIC is not only in using rip relative addressing, but also in the usage the GOT and the PLT tables, for doing calls. The relocation of the position dependent code of executables happens in linking time, long before load time.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_121704980726567103gmail-im">> On 21 Feb 2017, at 10:35, Ronie Salgado <<a href="mailto:roniesalg@gmail.com" target="_blank">roniesalg@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> I was debugging a strange crash when calling sqrt via a Lowcode
instruction in the interpreter, which I tracked to currentBytecode
stored in register(EBX), having a very large value. When debugging the
generated assembly code with GDB, I noticed that GCC was generating
position independent code and using EBX for doing a call without
spilling/unspilling its value.<br>
<br>
</span>Can you elaborate on the misbehavior? As of the ABI[1] EBX is a
local register, can GCC know that EBX has been used for something else? </blockquote><br>spursrc/vm/gcc3x-cointerp.c:<br><br>sqInt<br>interpret(void)<br>{ DECL_MAYBE_SQ_GLOBAL_STRUCT<br> register sqInt currentBytecode CB_REG;<br>...<br><br>platforms/unix/vm/sqGnu.h:<br><br>#elif defined(__i386__)<br># define IP_REG __asm__("%esi")<br># define SP_REG __asm__("%edi")<br># if (__GNUC__ > 2) || ((__GNUC__ == 2) && (__GNUC_MINOR__ >= 95))<br># define CB_REG __asm__("%ebx")<br># else<br># define CB_REG /* avoid undue register pressure */<br># endif<br><br><br></div>GDB session:<br><br>(gdb) list interpret<br>2604 /* If stacklimit is zero then the stack pages have not been initialized. */<br>2605 <br>2606 /* StackInterpreter>>#interpret */<br>2607 sqInt<br>2608 interpret(void)<br>2609 { DECL_MAYBE_SQ_GLOBAL_STRUCT<br>2610 register sqInt currentBytecode CB_REG;<br>2611 sqInt extA;<br>2612 sqInt extB;<br>2613 sqInt lkupClassTag;<br>(gdb) break 25313<br>Punto de interrupción 1 at 0x55c77: file /home/ronie/projects/osvm-lowcode-clean/spurlowcodesrc/vm/gcc3x-cointerp.c, line 25313.<br>(gdb) break 25314<br>Punto de interrupción 2 at 0x55c9b: file /home/ronie/projects/osvm-lowcode-clean/spurlowcodesrc/vm/gcc3x-cointerp.c, line 25314.<br>(gdb) break 25315<br><br>25313 result14 = sqrt(value17);<br>25314 /* begin internalPushFloat32: */<br>25315 nativeSP = (nativeStackPointerIn(localFP)) - BytesPerOop;<br><br>Nota: punto de rotura 2 también fijar en pc 0x55c9b.<br>Punto de interrupción 3 at 0x55c9b: file /home/ronie/projects/osvm-lowcode-clean/spurlowcodesrc/vm/gcc3x-cointerp.c, line 25315.<br>(gdb) run<br>Starting program: /home/ronie/projects/osvm-lowcode-clean/products/debug/phcoglowcodelinuxht/lib/pharo/5.0-201702210706-LowcodeFixup/pharo <br>[Depuración de hilo usando libthread_db enabled]<br>Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".<br>[Nuevo Thread 0xf728db40 (LWP 4716)]<br><br>Thread 1 "pharo" hit Breakpoint 1, interpret () at /home/ronie/projects/osvm-lowcode-clean/spurlowcodesrc/vm/gcc3x-cointerp.c:25313<br>25313 result14 = sqrt(value17);<br>(gdb) print currentBytecode<br>$1 = 504<br>(gdb) info registers<br>eax 0xf778f009 -143069175<br>ecx 0x5678ec88 1450765448<br>edx 0xf778f009 -143069175<br>ebx 0x1f8 504<br>esp 0xfffc2540 0xfffc2540<br>ebp 0xfffc6558 0xfffc6558<br>esi 0x594e702d 1498312749<br>edi 0xfffcb390 -216176<br>eip 0x565aac77 0x565aac77 <interpret+214836><br>eflags 0x282 [ SF IF ]<br>cs 0x23 35<br>ss 0x2b 43<br>ds 0x2b 43<br>es 0x2b 43<br>fs 0x0 0<br>gs 0x63 99<br>(gdb) continue<br>Continuando.<br><br>Thread 1 "pharo" hit Breakpoint 2, interpret () at /home/ronie/projects/osvm-lowcode-clean/spurlowcodesrc/vm/gcc3x-cointerp.c:25315<br>25315 nativeSP = (nativeStackPointerIn(localFP)) - BytesPerOop;<br>(gdb) info registers<br>eax 0xf778f009 -143069175<br>ecx 0x5678ec88 1450765448<br>edx 0x127f 4735<br>ebx 0x5678ec88 1450765448<br>esp 0xfffc2540 0xfffc2540<br>ebp 0xfffc6558 0xfffc6558<br>esi 0x594e702d 1498312749<br>edi 0xfffcb390 -216176<br>eip 0x565aac9b 0x565aac9b <interpret+214872><br>eflags 0x282 [ SF IF ]<br>cs 0x23 35<br>ss 0x2b 43<br>ds 0x2b 43<br>es 0x2b 43<br>fs 0x0 0<br>gs 0x63 99<br>(gdb) print currentBytecode<br>$2 = 1450765448<br><br></div>GDB layout asm on the line 25313 shows the generated code.<br><br>B+>│0x565aac77 <interpret+214836> flds -0x1d6c(%ebp) │<br> │0x565aac7d <interpret+214842> sub $0x8,%esp │<br> │0x565aac80 <interpret+214845> lea -0x8(%esp),%esp │<br> │0x565aac84 <interpret+214849> fstpl (%esp) │<br> │0x565aac87 <interpret+214852> mov -0x4008(%ebp),%ebx │<br> │0x565aac8d <interpret+214858> call 0x56570840 <br><br><br></div>Of special importance, is the instruction: mov -0x4008(%ebp),%ebx . this is the PLT entry for sqrt, and this is where ebx with the currentBytecode is destroyed.<br><br></div><div></div>Best regards,<br></div>Ronie<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-21 22:35 GMT-03:00 Holger Freyther <span dir="ltr"><<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> On 21 Feb 2017, at 10:35, Ronie Salgado <<a href="mailto:roniesalg@gmail.com">roniesalg@gmail.com</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> I was debugging a strange crash when calling sqrt via a Lowcode instruction in the interpreter, which I tracked to currentBytecode stored in register(EBX), having a very large value. When debugging the generated assembly code with GDB, I noticed that GCC was generating position independent code and using EBX for doing a call without spilling/unspilling its value.<br>
<br>
</span>Can you elaborate on the misbehavior? As of the ABI[1] EBX is a local register, can GCC know that EBX has been used for something else?<br>
<br>
holger<br>
<br>
[1] <a href="http://www.sco.com/developers/devspecs/abi386-4.pdf" rel="noreferrer" target="_blank">http://www.sco.com/developers/<wbr>devspecs/abi386-4.pdf</a></blockquote></div><br></div>