[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Calling x86 code from 64-bit code



paul@codesourcery.com (Paul Brook)  wrote on 15.12.03 in <12Zyo-2fp-1@gated-at.bofh.it>:

> 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  
system call.)

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
> compiler/linker.

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  
definitely nontrivial.

MfG Kai



Reply to: