[FFmpeg-cvslog] r29011 - in trunk/libswscale: swscale.c swscale_internal.h swscale_template.c
Mon Mar 23 11:12:37 CET 2009
On Mon, Mar 23, 2009 at 10:42:27AM +0100, Gwenole Beauchesne wrote:
> On Mon, 23 Mar 2009, Reimar D?ffinger wrote:
> > On Mon, Mar 23, 2009 at 09:33:40AM +0100, Gwenole Beauchesne wrote:
> >> On Fri, 20 Mar 2009, Reimar D?ffinger wrote:
> >>> I have no idea and not much interest and would not exclude a compiler
> >>> bug, but it might well be a provision intended to allow combining 32 and
> >>> 64 bit code, preserving the PIC pointer in rbx for use as ebx by any 32
> >>> bit code.
> >> This is not possible. On some ancient x86_64 implementation, it was
> >> (unofficially) possible to mix both but the engineers later on discouraged
> >> this as the actual implementation was to be changed. I am talking of the
> >> implementation (processor), the specs clearly forbids this.
> > Forbid what? Certainly not switching between 64 bit and 32 bit code,
> > then you couldn't run 32 bit programs at all anymore...
> Mixing 64-bit and 32-bit execution code paths in the same binary
> (user-code). Executing 32-bit binary on x86_64 is no issue and doesn't
> require an explicit mode switch *in* the generated application.
You didn't say what exactly the specification is supposed to forbid.
does not mention any restrictions (see in particular 6.3.1) and I don't
see any way to forbid it that wouldn't cause quite a lot of issues
(except making far jumps a privileged instruction, which could cause
issues with existing 32 bit applications and would uselessly waste
transistors on the CPU).
> e.g. opening an x86_32 DSO within an x86_64 binary and executing code from
> the library is not allowed, though technically possible on some
Since a CPU knows nothing about DSOs that is at best a confusing
More information about the ffmpeg-cvslog