Re: [Qemu-devel] Porting QEMU to PalmOS
On 01/07/07, Luke-Jr <[EMAIL PROTECTED]> wrote: On Sunday 01 July 2007 07:29, andrzej zaborowski wrote: > On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: > > 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++) Referring to this sentence ^ > > (Happily violating the GPL) > > Will the qemu port also be binary only? What did he say that violates the GPL? Just because he is only porting the isapc stuff? I don't know any part of the GPL saying "when you port this, you must port all the features"... Or would such a port be inherently a violation due to system libraries being incompatible with the [L]GPL? Releasing the dosbox PalmOS binary and not releasing the sources even when explicitly asked to is a violation of GPL and of the policy of sourceforge.net and a couple of other websites on which the binary appears. Regards
Re: [Qemu-devel] Porting QEMU to PalmOS
Hi, On Sun, 1 Jul 2007, Luke-Jr wrote: > On Sunday 01 July 2007 07:29, andrzej zaborowski wrote: > > On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: > > > > > [...] When I ported dosbox (which is written in c++) > > > > (Happily violating the GPL) > > > > Will the qemu port also be binary only? > > What did he say that violates the GPL? I think he was talking about dosbox. And expressing an implicit interest that whatever will be ported from qemu be handled differently. Ciao, Dscho
Re: [Qemu-devel] Porting QEMU to PalmOS
On Sunday 01 July 2007 07:29, andrzej zaborowski wrote: > On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: > > 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++) > > (Happily violating the GPL) > > Will the qemu port also be binary only? What did he say that violates the GPL? Just because he is only porting the isapc stuff? I don't know any part of the GPL saying "when you port this, you must port all the features"... Or would such a port be inherently a violation due to system libraries being incompatible with the [L]GPL?
Re: [Qemu-devel] Porting QEMU to PalmOS
On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: 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++) (Happily violating the GPL) Will the qemu port also be binary only? Sorry for being off-topic. Regards
Re: [Qemu-devel] Porting QEMU to PalmOS
Hi, thanks for the tip about position-independent. I did compile with -fno-pic, and the op.h was then generated without error. Now I have a different problem that might be related to PIC. The thing is, because of the nature of PalmOS, I had to link with -fPIC. Now, after removing the faults, I have reached the execution loop in cpu-exec.c and invoking of gen_func, nothing is realy happening, the loop is being executed, but after printing the data at the address of gen_func, I could see that there are all zeroes. Might that be because of linking with -fPIC? If so, I will have to use different way to link it, and it might take a while. If not, where to search for the fault? I have also debugged the host_alarm_handler, and found out that although realtime timer expires, it is not initialized again. Where exactly in the code is it done? I tried to find the place, but those timer functions are structure members, and it is hard to find a place. /Voda - Original Message From: Wolfgang Schildbach <[EMAIL PROTECTED]> To: qemu-devel@nongnu.org Sent: Wednesday, May 23, 2007 5:23:51 PM Subject: Re: [Qemu-devel] Porting QEMU to PalmOS Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > To: sinisa marovic <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > 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. Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
Re: [Qemu-devel] Porting QEMU to PalmOS
Palm API reference: http://www.access-company.com/developers/documents/docs/palmos/PalmOSReference/ReferenceTOC.html You'll need to install (with ports, apt-get, or what have you): m68k-palmos-gcc m68k-palmos-gdb (not required, but very useful) m86k-palmos-binutils palmos sdk pilrc PalmOS has its own C library, which makes it painfully frustrating to code for at times. The API reference is invaluable. Good luck. On Thu, May 24, 2007 at 04:33:26PM -0700, Jonathan Kalbfeld wrote: > Still sounds fantistically fun. > > Maybe you can point me in the right direction to write PalmOS programs > (.prc's right?). > > I have some goofy ideas for things to write for my Treo. > > jonathan > > On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: > > > > 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 <[EMAIL PROTECTED]> > > To: qemu-devel@nongnu.org > > 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 < > > [EMAIL PROTECTED]> wrote: > > > > > > Try compiling as position-dependent (i.e. not PIC) code. GOT is a > > > typical > > > feature of position independent code. > > > > > > - Wolfgang > > > > > > [EMAIL PROTECTED] > > > 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 < [EMAIL PROTECTED]> > > > > To: sinisa marovic <[EMAIL PROTECTED]> > > > > Cc: qemu-devel@nongnu.org > > > > 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 > > > > > > -- > > Get the free Yahoo! > > toolbar<http://us.rd.yahoo.com/evt=48226/*http://new.toolbar.yahoo.com/toolbar/features/norton/index.php>and > > > > rest assured with the added security of spyware protection. > > > > > > -- > -- > Jonathan Kalbfeld > +1 323 620 6682 pgpSH8Pul5NJ5.pgp Description: PGP signature
Re: [Qemu-devel] Porting QEMU to PalmOS
It sure is. I use prc-tools. It is free, and, well, it's gcc. There is also developer suite called CodeWarrior, but that is for wimps ;) (expensive too). I can give you some guidelines off the mailing list (I do not think others are interested in coding for palm). - Original Message From: Jonathan Kalbfeld <[EMAIL PROTECTED]> To: qemu-devel@nongnu.org Sent: Friday, May 25, 2007 1:33:26 AM Subject: Re: [Qemu-devel] Porting QEMU to PalmOS Still sounds fantistically fun. Maybe you can point me in the right direction to write PalmOS programs (.prc's right?). I have some goofy ideas for things to write for my Treo. jonathan On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: 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 < [EMAIL PROTECTED]> To: qemu-devel@nongnu.org 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 < [EMAIL PROTECTED]> wrote: Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] 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 < [EMAIL PROTECTED] > > To: sinisa marovic <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > 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 Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. -- -- Jonathan Kalbfeld +1 323 620 6682 Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
Re: [Qemu-devel] Porting QEMU to PalmOS
Still sounds fantistically fun. Maybe you can point me in the right direction to write PalmOS programs (.prc's right?). I have some goofy ideas for things to write for my Treo. jonathan On 5/24/07, sinisa marovic <[EMAIL PROTECTED]> wrote: 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 <[EMAIL PROTECTED]> To: qemu-devel@nongnu.org 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 < [EMAIL PROTECTED]> wrote: > > Try compiling as position-dependent (i.e. not PIC) code. GOT is a > typical > feature of position independent code. > > - Wolfgang > > [EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]> > > To: sinisa marovic <[EMAIL PROTECTED]> > > Cc: qemu-devel@nongnu.org > > 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 -- Get the free Yahoo! toolbar<http://us.rd.yahoo.com/evt=48226/*http://new.toolbar.yahoo.com/toolbar/features/norton/index.php>and rest assured with the added security of spyware protection. -- -- Jonathan Kalbfeld +1 323 620 6682
Re: [Qemu-devel] Porting QEMU to PalmOS
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 <[EMAIL PROTECTED]> To: qemu-devel@nongnu.org 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 <[EMAIL PROTECTED]> wrote: Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] 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 < [EMAIL PROTECTED]> > To: sinisa marovic <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > 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 Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
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 <[EMAIL PROTECTED]> wrote: Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > To: sinisa marovic <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > 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
Re: [Qemu-devel] Porting QEMU to PalmOS
Wow, if you can make this work I will be thrilled. I <3 my Treo 650. jonathan On 5/23/07, Wolfgang Schildbach <[EMAIL PROTECTED]> wrote: Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > To: sinisa marovic <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > 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
Re: [Qemu-devel] Porting QEMU to PalmOS
Try compiling as position-dependent (i.e. not PIC) code. GOT is a typical feature of position independent code. - Wolfgang [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > To: sinisa marovic <[EMAIL PROTECTED]> > Cc: qemu-devel@nongnu.org > 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.
Re: [Qemu-devel] Porting QEMU to PalmOS
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 <[EMAIL PROTECTED]> To: sinisa marovic <[EMAIL PROTECTED]> Cc: qemu-devel@nongnu.org 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 TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/
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
[Qemu-devel] Porting QEMU to PalmOS
Hi, I started porting QEMU to PalmOS. I already ported some projects successfuly (Like UAE and dosbox) but dosbox is so slow. QEMU has less compatibility with games but it is much faster. Now, I am having some problems with dyngen. Since QEMU supports ARM hosts I do not have to modify the code. Detailed description of the problem follows: Dyngen is used to create op.h, opc.h and gen-op.h during compilation. Since it is not possible to do the actual compilation on Palm itself, I thought of creating dyngen executable on the compilation host (PC with cygwin) and QEMU would then be built for execution host (Palm). This idea worked fine, but when dyngen was executed to create op.h I got an error: "Unsupported data relocation." I did some debugging to find out what the actual problem is, and this is what I found out: 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? Regards, Voda. Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
