Issue 2 in iotools: build fails on x86 w/PIE due to non-PIC inline asm code

[iot...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 2 by vap...@chromium.org: build fails on x86 w/PIE due to non-PIC
inline asm code
http://code.google.com/p/iotools/issues/detail?id=2

the cpuid code in misc.c is pretty easy to fix. see attached patch.

Attachments:
iotools-1.4-cpuid-pic.patch 564 bytes

[iot...@googlecode.com]

Comment #1 on issue 2 by thoc...@gmail.com: build fails on x86 w/PIE due to

non-PIC inline asm code
http://code.google.com/p/iotools/issues/detail?id=2

I don't understand the problem. Shouldn't the compiler restore EBX if it
is using it for PIC code? This looks like a hack that uses knowledge of
the compiler's behavior to work around a problem that shouldn't exist

I can reproduce it on -m32. Fix is coming.

[iot...@googlecode.com]

Updates:
Status: Fixed

Comment #2 on issue 2 by thoc...@gmail.com: build fails on x86 w/PIE due to

non-PIC inline asm code
http://code.google.com/p/iotools/issues/detail?id=2

(No comment was entered for this change.)

[iot...@googlecode.com]

Comment #3 on issue 2 by vap...@chromium.org: build fails on x86 w/PIE due

to non-PIC inline asm code
http://code.google.com/p/iotools/issues/detail?id=2

you'd think gcc would be smart/nice enough to do this for you. sadly, it
is not. it's a long standing feature of gcc that the gcc devs are aware of
but have no plans to change.

so yes, this code effectively does the ebx save/restore for gcc. but since
this has been the status quo for many many years and many many gcc
releases, i don't consider it a hack. just "the way things are done".