On Tue, Dec 25, 2012 at 8:27 PM, Mike Frysinger <vap...@gentoo.org> wrote:
>> >> In the case of cpuid, the code is hardly performance sensitive, and >> >> probably runs only at startup. An alternative solution for the broken >> >> code here is to move the result from rbx to another register, and to >> >> save/restore rbx. Currently, this is the only place in libgcc and >> >> newlib affected by this problem. >> > >> > it's not a question of performance. i can't remember how many various >> > projects i've had to tweak the inline asm code to work with __PIC__ >> > (either because it's going into shared library code or it's being built >> > as a PIE). Andi's point is now we have to redo all of that work a 2nd >> > time and handle two different cases depending on gcc version ? it'd be >> > a _lot_ better if gcc were intelligent and end users didn't have to code >> > crap like stuffing %ebx somewhere temporarily. >> >> Please note that we are not talking about 32bit code, where this would >> make a difference, but for 64bit targets with -mcmodel=medium and >> -mcmodel=large exclusively. The default x64_64 -mcmodel=small doesn't >> use PIC register, other code models are rarely used, so I sincerely >> doubt that any %rbx workarounds were needed in the past for x86_64. > > i'm aware. the comment still applies. you're breaking asm code that used to > work because the gcc inline asm code isn't intelligent enough (currently) to > transparently handle the PIC register for the user. Can you please post a real-world example, where using %r15 would break existing code? Uros.
