Re: [Qemu-devel] qemu vs gcc4
Martin Guy wrote: Now, gcc4 can produce code with several return instructions (with no option to turn that of, as far as I understand). You cannot cut them out, and therefore you cannot chain the simple functions. ...unless you also map return instructions within the generated functions into branches to the soon-to-be-dropped final return? Not that I know anything about qemu internals mind u... Seems to me one could also map them into jumps to a null function. Although, all told, it would seem to me that what might be called for here is a new gcc target. A gcc target specifically for generating qemu code. That would just simply generate whatever qemu wanted for function postamble. It would probably mean separating out the code intended to run as native code from the code intended to run on behalf of the emulated target, and it would mean that you'd need a gcc-qemu to build the latter, but it would solve the problem permanently. It could also then be done in a cpu independent fashion such that any gcc target port might be converted trivially into a gcc target-for-qemu port. This should also make the chaining task much simpler and since that would seem to need to be done at run time, this could easily be a performance enhancement as well. I see two real downsides to this approach. The first is that qemu becomes wed to gcc. That seems to be a defacto requirement now, but using a custom gcc target would make that marriage pretty permanent. Creating qemu targets for other compilers would be near impossible, although if the code were properly separated, you could still use a non-gcc target for the intended-for-host instructions. The second downside is that some of the qemu support stuff would no longer be in the qemu code distribution. Instead, it would be in gcc. This opens the possiblity for version slew problems and authority over maintenance issues in the long term. Administratively, it'd be an additional load. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] config file support
Rob Landley wrote: On Wednesday 18 October 2006 2:42 pm, Chuck Brazie wrote: Is there any work going on now to add config file support? Chuck Brazie [EMAIL PROTECTED] As a random end-user, I really like being able to run qemu without a config file, configuring it entirely on the command line. I'd be highly disappointed if qemu turned into another Wine. Except that I never do. Instead, I write a trivial shell script since I can never remember the command line options, much less type them in consistently. What's the difference between a shell script to cover qemu and a #!/bin/qemu config file? Seems to me they both address roughly the same issues with roughly the same considerations. Am I missing any significant functionality differences? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vs gcc4
Johannes Schindelin wrote: On Sun, 22 Oct 2006, Rob Landley wrote: Basically, gcc changed in a way that broke qemu. Yes, they did. But even if I understand your frustration (which I share), I also understand the gcc people. After all, using gcc to create the blocks for dynamic translation is a _hack_. Yes, it is a hack. And short of some guarantees from gcc, (which we don't have), it is destined to be an ongoing issue. The result of a compiler run, though, should work and run -- as fast as possible. So basically, the gcc people want to achieve a different goal from what we misuse their program for. Creating a qemu variant target for gcc would address both of these concerns. It would introduce new ones, of course, but it would address these two. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] config file support
Rob Landley wrote: What's the difference between a shell script to cover qemu and a #!/bin/qemu config file? The shell script works now, and you're proposing breaking it? No, I'm not. I'm genuinely asking about functional differences. Am I missing any significant functionality differences? So you'd have no trouble configuring kde's file type associations to open arbitrary "*.img" files with qemu when you click on them if you couldn't do this entirely from the command line? I don't use kde. And *.img is used for far too many file types to assume that this alone indicates that any foo.img is a qemu related file. But yes, I could configure gnome to do this. Or firefox. It's pretty much trivial. MacosX has file system metadata to help out so that it doesn't have to rely solely on the irrelevant file name suffixes. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vs gcc4
Could someone please explain the issue with gcc4, please? Or point me to an existing explanation? I mean, I understand that qemu is believed to be building incorrectly with gcc4. But what is the failure mode folks have been seeing? And what's being done about it or what needs to be done about it? Is this an issue for all targets or is it x86 specific? Thanks, --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Blue Swirl wrote: BTW, we could easily design and implement an ideal CPU just for Qemu purposes. It could be unlike any existing hardware, for example with zero or thousands of registers. The problem would be making a compiler for the CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS research projects? This idea has been around for a long time. When I was in school, one of our projects was to build a processor for such an architecture. The idea has been kicked around the gnu development toolchain community for some time as well. Gcc is sexy. You shouldn't have any trouble finding a student or another volunteer who's interested in implementing a simple, relatively orthogonal instruction set. Gas is harder. It's not so sexy. Nor is ld, nor gdb. Porting linux at that point is pretty much just a matter of determining cpu start and load addresses. Note: mmu management would also be a modest task, either to implement or to circumvent. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Johannes Schindelin wrote: This s reminds me of Java. Or lisp. :-). --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-system-sparc question?
Ishwar Rattan wrote: Is it possible to boot the iso image debian-31r3-sparc-netinst.iso in qemu-system-sparc? What about other Linux distributions? I haven't tried it. But I'd be curious to hear how it works for you. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm user mode
Paul Brook wrote: 1) Paul's patch for NLS. You mean TLS and/or NPTL. NLS is something completely different :-) Bah. Of course you're right. And I'm sure you can explain your patch better than I can. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm user mode
I have now managed to run a null program and a helloworld, (both eabi, linked statically, and without any thread calls), using the qemu-arm user mode, both inside and outside of scratchbox. To do this with qemu-0.8.2 I needed the following: 1) Paul's patch for NLS. http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html Note that you will need to remove your object directory, reconfigure, and rebuild after patching. The patch changes configuration data which will not be updated from a simple rebuild so you will need to remove your object and reconfigure before building again. I didn't notice and this held me up for several days. 2) to build a qemu that can be debugged, you'll need to build it statically. To do this, you can configure qemu using --static. 3) qemu cannot be built with gcc-4, (due to a problem I don't understand), nor with gcc-3 using -O0, (due to an apparent collision between register allocation and inlining). You'll need to use a gcc-3, with at least -O1 if you want to debug. I changed the -O values by editing the Makefiles directly, but this change isn't really necessary if you don't plan to debug qemu. 4) Configure using --enable-uname-revision=2.6.16. Paul partially explained this recently. Glibc, (the one your target program linked against when it was compiled), runs a check to see what kernel version it's running over. When qemu-user emulates this call, by default, it asks the underlying host kernel what version the underlying host kernel is and then tells gdb that the emulated kernel version is the same. While there's an argument that this is reasonable, in the case of arm eabi, it's a problem for many people. Since eabi support was only added to the kernel in 2.6.16, earlier kernels can't handle eabi kernel calls. Glibc knows this and will fail out if it believes itself to be running on an older kernel. The fix, then, is to either run qemu-arm with the command line option, -r 2.6.16 or to configure using --enable-uname-revision=2.6.16 which will ask qemu to simply report these version numbers rather than querying the underlying host kernel. (Note: if your underlying (x86) host kernel happens to be 2.6.16 or later, then you probably don't need this workaround.) None of these are new issues or fixes. It just took me a few days to collect, run into them, and sort through them all. So I'm posting my results here. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm is a shared library?
When I build qemu-0.8.2, qemu-arm is a shared library rather than being an executable. This seems highly suspicious and makes it particularly difficult to debug. What's the rationale behind this? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu arm eabi (armel)
Paul Brook wrote: On Tuesday 26 September 2006 23:14, K. Richard Pixley wrote: Ok, then I'm confused because I'm seeing dumps just trying to run a null program. Unless there's NPTL setup stuff in crt0, I can't guess what might be going on yet. This same null binary runs on a qemu-system with suitable rootfs kernel. The glibc startup code contains TLS initialisation that will fail on unpatched qemu. If you have applied the TLS patch there are a couple of other things that could cause problems: - Make sure it's picking up the correct target shared libraries (or link your test application statically). Done. - Try configuring qemu with --static. The default (building qemu as a shared library) seems to cause strange problems on many systems. Done. - Make sure uname -r reports at least 2.6.16 (qemu can lie for you). Ah. Hm.. ubuntu-5 is currently: [EMAIL PROTECTED] uname -a Linux svrpixleylnx 2.6.12-10-686-smp #1 SMP Tue Jul 18 23:03:01 UTC 2006 i686 GNU/Linux Do you know why 2.6.16 would be required? (I'll see if I can't find/build a 2.6.16 system on which to try it today.) --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu arm eabi (armel)
Paul Brook wrote: Do you know why 2.6.16 would be required? (I'll see if I can't find/build a 2.6.16 system on which to try it today.) Because arm-linux didn't get EABI support until 2.6.16 (though our toolchains may accept 2.6.14). glibc has santity checks stop applications even trying to run on kernels that are too old. As I mentioned qemu lie about the kernel version. See -r and --enable-uname-release. I'm confused. My host kernel, (hosted on an x86 ubuntu box), is: [EMAIL PROTECTED] uname -r 2.6.12-10-686-smp And my understanding is that there is no kernel when running qemu-user because qemu is emulating the kernel calls. What am I missing? Or where does the kernel version come into play? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu arm eabi (armel)
Does anyone have qemu running in user emulation with arm eabi, (armel), traps? I can get qemu-system booting an armel system. And I can get qemu-user running with the codesourcery gcc-3 eabi libc's, (ie, the ones with the codesourcery kernel call shims), but I haven't gotten it working yet with eabi kernel calls in user mode. Should this be expected to work in 0.8.2? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu arm eabi (armel)
Ok, then I'm confused because I'm seeing dumps just trying to run a null program. Unless there's NPTL setup stuff in crt0, I can't guess what might be going on yet. This same null binary runs on a qemu-system with suitable rootfs kernel. --rich [EMAIL PROTECTED] ./qemu-arm --version qemu-arm version 0.8.2, Copyright (c) 2003-2005 Fabrice Bellard [...] [EMAIL PROTECTED] ./qemu-arm ./null qemu: uncaught target signal 11 (Segmentation fault) - exiting ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?
I have at least one 450Mhz k6 in my spare bedroom. I'll by happy to sell it to you as a platform for running debian and qemu. I'm sure it's performance would be lower than most of the current amd processors, though it might not be slower than some of the current intel chips, (*grin*). --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Are the new arm targets working?
Are the new arm targets, versatile[ap]b expected to be working? On ubuntu-5, building 0.8.2 yields a binary which can run the other two targets, but which hangs after printing the monitor prompt on either of these. --rich (apologies if you see this multiple times. I thought I sent it previously, but I didn't see it echoed back.) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Are the new arm targets working?
Are the new arm targets, versatile[ap]b expected to be working? On ubuntu-5, building 0.8.2 yields a binary which can run the other two targets, but which hangs after printing the monitor prompt on either of these. --rich (apologies if you see this twice. I thought I sent it last week, but I didn't see it echoed back.) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Are the new arm targets working?
Are the new arm targets, versatile[ap]b expected to be working? On ubuntu-5, building 0.8.2 yields a binary which can run the other two targets, but which hangs after printing the monitor prompt on either of these. --rich (apologies if you see this twice. I thought I sent it yesterday, but I didn't see it echoed back.) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Are the new arm targets working?
Are the new arm targets, versatile[ap]b expected to be working? On ubuntu-5, building 0.8.2 yields a binary which can run the other two targets, but which hangs after printing the monitor prompt on either of these. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC] Allow trying to boot from multiple devices
Jeremy Katz wrote: The bochs rombios has supported attempting to boot from more than one device for a while. It seems like it would make sense to be able to specify -boot acd as an argument for qemu to try booting first from the floppy, then the cd and finally the hard drive to make things more like a real machine. Does this seem reasonable? It would make some things like installing guests, (which tend to want to reboot from the hard disk they've just populated from ether/cd/dvd/whatever), easier. --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] eabi support for arm?
Can anyone tell me if there's any work going on to support eabi for arm? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
