[Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[Paul Robinson]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Hi guys,

I'm trying to use parts of qemu in an application that must be compiled
as a shared library (i.e. a .so file).
The code must be compiled with the -fPIC option otherwise the linker
refuses to create a .so file
but doing this causes dyngen to stop with the error:
../dyngen -o op.h op.o
dyngen: unsupported X86_64 relocation (9)

In dyngen-exec.h, if I change
extern int __op_param1, __op_param2, __op_param3;
to
static int __op_param1, __op_param2, __op_param3;
then dyngen stops with
dyngen: unsupported X86_64 relocation (4)

I suspect that I need to resort to assembly language (as has been done
for alpha hosts).

My question is:
Has anyone already done this ? (so I don't have to re-invent the wheel).

The nearest I've found so far is Johannes Schindelin's "Porting QEMU to
[a] new CPU" guide.

Regards,
Paul R.

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

Re: [Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[Paul Brook]

On Friday 03 November 2006 18:15, Paul Robinson wrote:
> Hi guys,
>
> I'm trying to use parts of qemu in an application that must be compiled
> as a shared library (i.e. a .so file).
> The code must be compiled with the -fPIC option otherwise the linker
> refuses to create a .so file
> but doing this causes dyngen to stop with the error:
> ../dyngen -o op.h op.o
> dyngen: unsupported X86_64 relocation (9)

More likely you just need to implement whetever relocation it's complaining 
about.

Paul

Re: [Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[Daniel Jacobowitz]

On Fri, Nov 03, 2006 at 09:42:18PM +0000, Paul Brook wrote:
> On Friday 03 November 2006 18:15, Paul Robinson wrote:
> > Hi guys,
> >
> > I'm trying to use parts of qemu in an application that must be compiled
> > as a shared library (i.e. a .so file).
> > The code must be compiled with the -fPIC option otherwise the linker
> > refuses to create a .so file
> > but doing this causes dyngen to stop with the error:
> > ../dyngen -o op.h op.o
> > dyngen: unsupported X86_64 relocation (9)
> 
> More likely you just need to implement whetever relocation it's complaining 
> about.

This is dyngen we're talking about - presumably that isn't the bit that
needs to be PIC?  Looks to me like the op file was compiled with the
PIC CFLAGS.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[G Portokalidis]

Hello Paul,
I also need to use qemu as a shared library, so i was wandering
whether you had any luck with this?

On 03/11/06, Paul Robinson <Paul.Robinson@scisys.co.uk> wrote:
>
>
>
> Hi guys,
>
> I'm trying to use parts of qemu in an application that must be compiled as a
> shared library (i.e. a .so file).
> The code must be compiled with the -fPIC option otherwise the linker refuses
> to create a .so file
> but doing this causes dyngen to stop with the error:
> ../dyngen -o op.h op.o
> dyngen: unsupported X86_64 relocation (9)
>
> In dyngen-exec.h, if I change
> extern int __op_param1, __op_param2, __op_param3;
> to
> static int __op_param1, __op_param2, __op_param3;
> then dyngen stops with
> dyngen: unsupported X86_64 relocation (4)
>
> I suspect that I need to resort to assembly language (as has been done for
> alpha hosts).
>
> My question is:
> Has anyone already done this ? (so I don't have to re-invent the wheel).
>
> The nearest I've found so far is Johannes Schindelin's "Porting QEMU to [a]
> new CPU" guide.
>
> Regards,
> Paul R.
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>

Re: [Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[G Portokalidis]

I managed to compile and use qemu as a shared library for the ii386
user space emulator.
I didn't use -fPIC to compile anything and simply generated the lib by
adding something like this in Makefile.target:
$(CC) -shared -Wl,-soname,libqemu.so.0 -o libqemu.so.0 	$(LIBOBJS) -lc

I am not sure it should work under all circumstances. It also works
when USE_CODE_COPY is not defined.



On 14/12/06, G Portokalidis <georgios.portokalidis@gmail.com> wrote:
> Hello Paul,
> I also need to use qemu as a shared library, so i was wandering
> whether you had any luck with this?
>
> On 03/11/06, Paul Robinson <Paul.Robinson@scisys.co.uk> wrote:
> >
> >
> >
> > Hi guys,
> >
> > I'm trying to use parts of qemu in an application that must be compiled as a
> > shared library (i.e. a .so file).
> > The code must be compiled with the -fPIC option otherwise the linker refuses
> > to create a .so file
> > but doing this causes dyngen to stop with the error:
> > ../dyngen -o op.h op.o
> > dyngen: unsupported X86_64 relocation (9)
> >
> > In dyngen-exec.h, if I change
> > extern int __op_param1, __op_param2, __op_param3;
> > to
> > static int __op_param1, __op_param2, __op_param3;
> > then dyngen stops with
> > dyngen: unsupported X86_64 relocation (4)
> >
> > I suspect that I need to resort to assembly language (as has been done for
> > alpha hosts).
> >
> > My question is:
> > Has anyone already done this ? (so I don't have to re-invent the wheel).
> >
> > The nearest I've found so far is Johannes Schindelin's "Porting QEMU to [a]
> > new CPU" guide.
> >
> > Regards,
> > Paul R.
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> >
> >
>

RE: [Qemu-devel] Compiling qemu as position-independent code on an x86_64 linux host

[Paul Robinson]

> Hello Paul,
> I also need to use qemu as a shared library, so i was wandering
whether you had any luck with this?
>
> On 03/11/06, Paul Robinson <Paul.Robinson@scisys.co.uk> wrote:
> >
...

Hello Georgios,
The short answer is not yet. I made a start but then had to do other
things.
I'll be looking at this again soon (hopefully in December) and will post
the diffs to the list.

Regards,
Paul R.