I'm afraid I will have to dissapoint you: it will be only isapc with no
networking or other fancy devices. Main goal is the ability to run dos games.
I do not know how familiar are you with PalmOS developer support. It
is poor, gcc lack many important functions that have to be written from
scratch. When I ported dosbox (which is written in c++) I realized that
there is no support for vectors, iterators, namespaces etc, so I had to
write many operators myself. The biggest problem with QEMU is that
it uses signals a lot, and, guess what, PalmOS has no support for signals
_at_ _all_. I found a way to get things going without them for now, but
this has it's drawbacks. I will have to think about something better later on.
----- Original Message ----
From: Jonathan Kalbfeld <address@hidden>
To: address@hidden
Sent: Thursday, May 24, 2007 11:18:48 PM
Subject: Re: [Qemu-devel] Porting QEMU to PalmOS
One definite plus with having QEMU for PalmOS is the ability to run things like OpenVPN (even if slow) and connect to a VPN back-end.
As is, I use OpenVPN tunnels to link up my QEMU machines on Solaris.
jonathan
On 5/23/07, Wolfgang Schildbach <address@hidden> wrote:
Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical
feature of position independent code.
- Wolfgang
qemu-devel-bounces+wolfgang.schildbach=address@hidden
wrote on 23.05.2007 13:20:22:
> Hi Johannes,
>
> thanks for your quick response.
> I thought QEMU was already compiled and run on an ARM machine?
> If so, how come that noone else had such problem (I searched for it
> on google),
> and PXA255 is a standard ARM CPU with a few additional instructions.
> And how to make them not come from GOT, those vars are declared as
extern,
> so they are globals?
>
> BR,
> Voda.
> -----
Original Message ----
> From: Johannes Schindelin < address@hidden>
> To: sinisa marovic <address@hidden>
> Cc: address@hidden
> Sent: Wednesday, May 23, 2007 12:48:59 PM
> Subject: Re: [Qemu-devel] Porting QEMU to PalmOS
> Hi,
>
> On Wed, 23 May 2007, sinisa marovic wrote:
>
> > Relocation types that fail are 25 and 26, which are R_ARM_GOTPC and
> > R_ARM_GOT32 respectively. Their names are:
> >
> > _GLOBAL_OFFSET_TABLE_
> > cc_table
> > __op_param1
> > __op_param2
> > __op_param3
> >
> > Is there a way to fix this?
>
> The GOT is an offset table. Many CPUs
have fixed-size instruction sets,
> which means that you cannot easily jump to an absolute address, since
the
> address alone would already fill up the size.
>
> Of course, this is a no-no for QEmu, since the _same_ function snippet
> will be reused _multiple_ times. So, the address must not come from a
GOT,
> but be inserted directly into the code.
>
> I do not remember off-hand how I managed to do this a couple of years
ago,
> when I worked on a MIPS host, but there _are_ gcc options to avoid a
GOT.
>
> Hth,
> Dscho
>
>
> Food fight? Enjoy some healthy debate
> in the Yahoo! Answers Food & Drink Q&A.
--
--
Jonathan Kalbfeld
+1 323 620 6682