Re: Calling x86 code from 64-bit code
firstname.lastname@example.org (Paul Brook) wrote on 15.12.03 in <12Zyoemail@example.com>:
> On Monday 15 December 2003 5:40 am, Xavier Roche wrote:
> > Paul Brook wrote:
> > > Not really. It can run both 32-bit and 64-bit processes under the
> > > control of a 64-bit kernel. Linking 32-bit libraries into 64-bit apps
> > > is for most practical purposes impossible.
> > The rellocation process is not done? This is something that could be
> > problematic Maybe there's a need for a "dlopen32" ?
> It's more than just relocation that is neccessary.
> > I don't think that function prelude/end should be adapted ; in fact
> > except symbol issues, and address space handling, this should be feasible
> > :)
> It's the "address space handling" that is the main problem. Think of
> pointers inside structs.
Worse than that.
As I understand amd64, you need to switch to a different code segment to
switch between 32 and 64 bit code (exactly the same as between 32 and 16
bit code); you can't do that unless the kernel has set up such a segment
for you. (Dosemu, for example, does something like that with the vm86
There may or may not also be a need for a different data and stack
segment, but if you can do one of these, you can do the others.
But essentially, think of such a switch as more like two separate
processes which share some memory than as of something like, say, the arm/
thumb switch. It is definitely NOT something that user mode can do on its
own, without help from the kernel.
> In some limited situations it is possible to generate thunks which copy all
> the required data from the 64-bit address space into a 32-bit one. However
> this requires very carefully written code and extra annotations for the
That's obviously another consideration; libffi or libffcall do stuff like
that (for a same-processor-mode context), so you might want to look there
to see how complex that can get. Doing stubs right in the generic case is