qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] target-mips: Add n32/n64 configuration file


From: Maciej W. Rozycki
Subject: Re: [Qemu-devel] [PATCH 1/3] target-mips: Add n32/n64 configuration files
Date: Thu, 11 Dec 2014 14:52:54 +0000
User-agent: Alpine 1.10 (DEB 962 2008-03-14)

On Thu, 11 Dec 2014, Peter Maydell wrote:

> >> >  Except that apart from coming to an agreement someone has to make it
> >> > happen yet. ;)
> >>
> >> Ah, but I'm happy with the current state of the codebase...
> >
> >  Ack.
> 
> To clarify, that was a slightly tongue-in-cheek response, but I
> do actually feel strongly enough that we shouldn't create new
> wrong executables that I'd rather we left the bugs here unaddressed
> than try to fix them with a lot of new softmmu executables.

 Sure, I have to clear the confusion I created here though.

 I have realised I ran all the earlier system emulation mode Linux testing 
with both o32 (ELF32) and n64 (ELF64) kernel images and just a single pair 
of QEMU executables for different endiannesses each.  So the ELF loader 
already supports all ELF executables.  So it's only the GDB stub's 
register width that has issues, as addressed here.

 Apologies for the wrong statements then, I misremembered things.

> >> Er, I'm not sure what you mean there. Trying a softmmu config for
> >> mipsn32 or mipsn32el fails gracefully already:
> >>
> >> manooth$ (cd build/mips && ../../configure --target-list=mipsn32-softmmu)
> >>
> >> ERROR: Unknown target name 'mipsn32-softmmu'
> >
> >  It looks like the issue I had in mind has been fixed in a generic way
> > then since I last checked.  Previously a build error happened sometime
> > along the process.  Apologies for not double-checking with current trunk.
> > I'll send updates.
> 
> Yes, we fixed configure to sanity check user target-list arguments
> some time last year. Note that the list of valid targets is driven
> by looking at what files exist in default-configs/, so you'll want
> to delete any stale or local files you have there from previous
> versions of this patchset.

 That's what I figured out before sending v2.  It looks to me like the 
cleanest way to handle it, you don't duplicate validity information in 
`configure'.

 Thanks for your review and hints, much appreciated.

  Maciej



reply via email to

[Prev in Thread] Current Thread [Next in Thread]