[1/3] target-mips: Add n32/n64 configuration files

Mechanically add new n32/n64 configuration files copying the relevant 
preexisting ones, fixing the system emulation configuration build, that 
breaks due to the lack of the respective configuration files, for the 
`mipsn32' and `mipsn32el' targets on this occasion as well.

Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
---
 To be applied first so as not to break the build and consequently 
bisection with the configuration changes posted next.

  Maciej

qemu-mips-configs.diff

On 10 December 2014 at 18:53, Maciej W. Rozycki <macro@codesourcery.com> wrote:
> Mechanically add new n32/n64 configuration files copying the relevant
> preexisting ones, fixing the system emulation configuration build, that
> breaks due to the lack of the respective configuration files, for the
> `mipsn32' and `mipsn32el' targets on this occasion as well.
>
> Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
> ---
>  To be applied first so as not to break the build and consequently
> bisection with the configuration changes posted next.
>
>   Maciej
>
> qemu-mips-configs.diff
> Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak
> Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak
> Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak
> Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak

Some of these look weird. n32 and n64 are ABIs, right? We
shouldn't have extra -softmmu configs for different ABIs,
the guest can deal with those. The MIPS config name variants
that are only ABI related should only result in new -linux-user
binaries (where we need a binary per Linux syscall ABI).

thanks
-- PMM

On Wed, 10 Dec 2014, Peter Maydell wrote:

> > Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak
> > Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak
> > Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak
> > Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak
> 
> Some of these look weird. n32 and n64 are ABIs, right? We
> shouldn't have extra -softmmu configs for different ABIs,
> the guest can deal with those. The MIPS config name variants
> that are only ABI related should only result in new -linux-user
> binaries (where we need a binary per Linux syscall ABI).

 This is a tricky change, the system emulation mode configuration also has 
an ELF loader (invoked with the -kernel option) and as such is also 
affected.  There are three MIPS ELF flavours corresponding to the three 
ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is 
an ELF file header flag).  The two ELF32 flavours are I think close enough 
to each other as far as executables (as opposed to intermediate objects) 
are concerned that a single QEMU binary might be able to handle them as it 
stands.  Of course ELF32 ABI2 is incompatible to any 32-bit processors and 
such executables must be rejected when emulating a 32-bit processor.

 So with my proposal and -softmmu configs:

- mipsn64|mipsn64el -- handle ELF64 (n64) binaries with only 64-bit 
                       processors available for emulation, 

- mipsn32|mipsn32el -- handle ELF32 (n32) binaries with only 64-bit 
                       processors available for emulation,

- mips64|mips64el   -- handle ELF32 (o32, maybe n32) binaries with both 
                       32-bit and 64-bit processors available for 
                       emulation,

- mips|mipsel       -- handle ELF32 (o32) binaries with only 32-bit 
                       processors available for emulation (configuration 
                       optimised for 32-bit hosts).

Each of them will be suitable for running different bare-metal 
applications.  As I say, we may be able to come up with better target 
names, I am open to proposals.

 As noted in 0/3 ideally we'd handle all ELF flavours with a single 
binary.  Then we could have two system configurations only, mips|mipsel (a 
limited configuration for 32-bit host optimisation) and mips64|mips64el (a 
full configuration).  That could apply to both the system and the user 
emulation mode, although the effort required to handle the former is a 
subset of that for the latter, and also looks quite substantially smaller 
to me.  The changes I propose here do not preclude it from happening in 
the future, they are merely intended to bring some order to what we have 
now.

 Does this explanation makes things addressed here a bit clearer to you?

  Maciej

On 10 December 2014 at 20:29, Maciej W. Rozycki <macro@codesourcery.com> wrote:
> On Wed, 10 Dec 2014, Peter Maydell wrote:
>
>> > Index: qemu-git-trunk/default-configs/mipsn32-softmmu.mak
>> > Index: qemu-git-trunk/default-configs/mipsn32el-softmmu.mak
>> > Index: qemu-git-trunk/default-configs/mipsn64el-linux-user.mak
>> > Index: qemu-git-trunk/default-configs/mipsn64el-softmmu.mak
>>
>> Some of these look weird. n32 and n64 are ABIs, right? We
>> shouldn't have extra -softmmu configs for different ABIs,
>> the guest can deal with those. The MIPS config name variants
>> that are only ABI related should only result in new -linux-user
>> binaries (where we need a binary per Linux syscall ABI).
>
>  This is a tricky change, the system emulation mode configuration also has
> an ELF loader (invoked with the -kernel option) and as such is also
> affected.  There are three MIPS ELF flavours corresponding to the three
> ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is
> an ELF file header flag).  The two ELF32 flavours are I think close enough
> to each other as far as executables (as opposed to intermediate objects)
> are concerned that a single QEMU binary might be able to handle them as it
> stands.  Of course ELF32 ABI2 is incompatible to any 32-bit processors and
> such executables must be rejected when emulating a 32-bit processor.

So this is only an issue because of the bare-metal ELF loading?
We should make that handle the various bare metal EXEs correctly
for the CPUs that each softmmu config currently supports.

>  As noted in 0/3 ideally we'd handle all ELF flavours with a single
> binary.  Then we could have two system configurations only, mips|mipsel (a
> limited configuration for 32-bit host optimisation) and mips64|mips64el (a
> full configuration).

I think this is the right way to go.

>  That could apply to both the system and the user
> emulation mode, although the effort required to handle the former is a
> subset of that for the latter, and also looks quite substantially smaller
> to me.

User emulation is a harder problem, because we compile-time code in
things like structure layouts and data type sizes. That's why we have
one binary per ABI. System emulation really should not care about
this anywhere near as much.

> The changes I propose here do not preclude it from happening in
> the future, they are merely intended to bring some order to what we have
> now.

The problem is that adding new QEMU executables is effectively
extending our user-facing interface. We really shouldn't do that
in the wrong way if we can avoid it (it's hard to undo later
without breaking peoples' setups).

thanks
-- PMM

On Wed, 10 Dec 2014, Peter Maydell wrote:

> >  This is a tricky change, the system emulation mode configuration also has
> > an ELF loader (invoked with the -kernel option) and as such is also
> > affected.  There are three MIPS ELF flavours corresponding to the three
> > ABIs: ELF32 no-ABI2 for o32, ELF32 ABI2 for n32 and ELF64 for n64 (ABI2 is
> > an ELF file header flag).  The two ELF32 flavours are I think close enough
> > to each other as far as executables (as opposed to intermediate objects)
> > are concerned that a single QEMU binary might be able to handle them as it
> > stands.  Of course ELF32 ABI2 is incompatible to any 32-bit processors and
> > such executables must be rejected when emulating a 32-bit processor.
> 
> So this is only an issue because of the bare-metal ELF loading?
> We should make that handle the various bare metal EXEs correctly
> for the CPUs that each softmmu config currently supports.
> 
> >  As noted in 0/3 ideally we'd handle all ELF flavours with a single
> > binary.  Then we could have two system configurations only, mips|mipsel (a
> > limited configuration for 32-bit host optimisation) and mips64|mips64el (a
> > full configuration).
> 
> I think this is the right way to go.

 Except that apart from coming to an agreement someone has to make it 
happen yet. ;)

> >  That could apply to both the system and the user
> > emulation mode, although the effort required to handle the former is a
> > subset of that for the latter, and also looks quite substantially smaller
> > to me.
> 
> User emulation is a harder problem, because we compile-time code in
> things like structure layouts and data type sizes. That's why we have
> one binary per ABI. System emulation really should not care about
> this anywhere near as much.

 We still need to come up with sensible target names and clean up the 
current situation.  What I think is particularly important about this 
series is 3/3.  And 2/3 defines a consistent set of macros to drive 3/3.

> > The changes I propose here do not preclude it from happening in
> > the future, they are merely intended to bring some order to what we have
> > now.
> 
> The problem is that adding new QEMU executables is effectively
> extending our user-facing interface. We really shouldn't do that
> in the wrong way if we can avoid it (it's hard to undo later
> without breaking peoples' setups).

 Fair enough, I want to move forward though.  Would it make you happy if I 
dropped the new -softmmu configs and made mipsn32|mipsn32el and 
mipsn64|mipsn64el only accept -user configs instead (failing gracefully 
rather than abruptly as mipsn32|mipsn32el do now)?

  Maciej

On 10 December 2014 at 22:14, Maciej W. Rozycki <macro@codesourcery.com> wrote:
> On Wed, 10 Dec 2014, Peter Maydell wrote:

>> >  As noted in 0/3 ideally we'd handle all ELF flavours with a single
>> > binary.  Then we could have two system configurations only, mips|mipsel (a
>> > limited configuration for 32-bit host optimisation) and mips64|mips64el (a
>> > full configuration).
>>
>> I think this is the right way to go.
>
>  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...

>> > The changes I propose here do not preclude it from happening in
>> > the future, they are merely intended to bring some order to what we have
>> > now.
>>
>> The problem is that adding new QEMU executables is effectively
>> extending our user-facing interface. We really shouldn't do that
>> in the wrong way if we can avoid it (it's hard to undo later
>> without breaking peoples' setups).
>
>  Fair enough, I want to move forward though.  Would it make you happy if I
> dropped the new -softmmu configs and made mipsn32|mipsn32el and
> mipsn64|mipsn64el only accept -user configs instead (failing gracefully
> rather than abruptly as mipsn32|mipsn32el do now)?

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'

thanks
-- PMM

On Wed, 10 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.

> >  Fair enough, I want to move forward though.  Would it make you happy if I
> > dropped the new -softmmu configs and made mipsn32|mipsn32el and
> > mipsn64|mipsn64el only accept -user configs instead (failing gracefully
> > rather than abruptly as mipsn32|mipsn32el do now)?
> 
> 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.

  Maciej

On 10 December 2014 at 23:25, Maciej W. Rozycki <macro@codesourcery.com> wrote:
> On Wed, 10 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.

>> 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.

thanks
-- PMM

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