Bugzilla Bug 200670

<snip>

  libtheora.so.0.3.1: (memory/data?) [0xCB76] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCB80] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCC30] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCC3A] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCD2B] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCD32] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCD3F] in (optimized out: previous
theora_decode_init) [0x33A0]
  libtheora.so.0.3.1: (memory/data?) [0xCD46] in (optimized out: previous
theora_decode_init) [0x33A0]
  /usr/lib/libtheora.so.0.3.1

</snip>

media-libs/libtheora-1.0_beta2 has USE pic to work this around for hardened,
but it should be fixed instead.

For the moment if the problems are limited to x86 then the ebuild should be
changed as follows.

-use pic && myconf="--disable-asm"
+use pic && use x86 && myconf="--disable-asm"

Please don't even think about ever package use masking the pic flag in any
profile. Hopefully we can find a better solution in which we can give 
everybody the best of all worlds.

Well, if the pic USE flag is limited to x86 it makes sense to package.use.mask
it in base/ and then unmask it on x86-based profiles, don't you think so? It
makes no sense for other profiles to ever see that flag, but as we can't hide
it we are left with masking it for the single ebuild involved.

pic is not limited to x86 in any such way. There is no reason to limit it to
any such profile.. We fix ebuilds at gentoo. Lets continue doing that..

Err when did I say it was limited to x86? I was proposing to let the USE flag
be a no-op for any other profile, because the _textrel_ problem is limited to
x86, no need to get other profiles to care about that USE flag.

Diego,
I know you want to be helpful and all but in this case, I'm asking you to
please 
let it go. The pic flag has it's uses. We like how it's used. Adding crap to 
profiles vs ebuilds where they belong over complicates the issue and makes 
it harder to find and fix at a later time. If you want to mask it in *BSD
profiles. Then by all means go for it. But please leave base/* hardened/*
default-linux/* selinux/* uclibc/* alone.

pageexec, could you take a look at this? thanks!

Created an attachment (id=137278) [details]
pic fix

it's probably possible to also gain one register in their inline asm so that
compiling without -fomit-frame-pointer won't fail.

please someone with real x86 hardware (not just a chroot like me) test this,
and please someone with better experience than me with such fixes (not
difficult to find) review the patch ;)

just a few comments:

1. textrels are not at all specific to x86, they can happen on any arch. in
practice you see them most on x86 because that's where people write asm code
most of the time *and* not take care of proper PIC.

2. the proposed fix looks correct but i haven't checked the whole environment,
so please make sure that whatever register is used as the PIC base register
(probably ebx) is not used in any way in the rest of the asm() block.

PS: speaking of textrels, would you guys take a look at bug #135326 please?

(In reply to comment #8)
> 2. the proposed fix looks correct but i haven't checked the whole environment,
> so please make sure that whatever register is used as the PIC base register
> (probably ebx) is not used in any way in the rest of the asm() block.

ebx is not used, but anyway, if it was used and not in the clobber list that
would be a much more serious issue than a textrel imho. And if it was used and
in the clobber list gcc would be ranting a lot, wouldn't it ?


> PS: speaking of textrels, would you guys take a look at bug #135326 please?

yes I was planning to jump on this one very soonish, but I need to find a
moment where I have a few hours free as the patch is huge and I want to review
it and test it entirely before commiting it.

Unfortunately, I don't have x86 hardware to test this (CC x86?)

(In reply to comment #9)
> ebx is not used, but anyway, if it was used and not in the clobber list that
> would be a much more serious issue than a textrel imho.

it's just that i saw in the past PIC 'fixes' where instead of getting rid of
ebx, it was simply pushed/popped around the rest of the code. the problem with
this is that it obviously changes the stack pointer which in turn will ruin
gcc's internal tracking logic and manifests in bad asm when you have an "m"
constraint for a variable that happens to be on the stack and is not addressed
via the frame pointer.

> And if it was used and in the clobber list gcc would be ranting a lot, wouldn't it ?

yes.

(In reply to comment #7)
> please someone with real x86 hardware (not just a chroot like me) test this,
> and please someone with better experience than me with such fixes (not
> difficult to find) review the patch ;)
> 
Applying fine on my x86, ffmpeg2theora also works fine w/ that.

applied