| Message ID | 1399537603-6905-4-git-send-email-dougkwan@google.com |
|---|---|
| State | New |
| Headers | show |
On 05/08/2014 10:26 AM, Doug Kwan wrote: > Add a new user mode target for little-endian PPC64. > > Signed-off-by: Doug Kwan <dougkwan@google.com> > --- > configure | 6 ++++++ > default-configs/ppc64el-linux-user.mak | 1 + > 2 files changed, 7 insertions(+) > create mode 100644 default-configs/ppc64el-linux-user.mak > > diff --git a/configure b/configure > index ac2fa15..ce44044 100755 > --- a/configure > +++ b/configure > @@ -4917,6 +4917,12 @@ case "$target_name" in > echo "TARGET_ABI32=y" >> $config_target_mak > gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" > ;; > + ppc64el) > + TARGET_ARCH=ppc64 > + TARGET_BASE_ARCH=ppc > + TARGET_ABI_DIR=ppc > + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" I can't see the part where this switches the ABI definition to be little endian? I'm sure that magic is hidden somewhere, mind to guide me to it? Alex
All the magic happens in the patch 2/3. On Thu, May 8, 2014 at 1:41 AM, Alexander Graf <agraf@suse.de> wrote: > On 05/08/2014 10:26 AM, Doug Kwan wrote: > >> Add a new user mode target for little-endian PPC64. >> >> Signed-off-by: Doug Kwan <dougkwan@google.com> >> --- >> configure | 6 ++++++ >> default-configs/ppc64el-linux-user.mak | 1 + >> 2 files changed, 7 insertions(+) >> create mode 100644 default-configs/ppc64el-linux-user.mak >> >> diff --git a/configure b/configure >> index ac2fa15..ce44044 100755 >> --- a/configure >> +++ b/configure >> @@ -4917,6 +4917,12 @@ case "$target_name" in >> echo "TARGET_ABI32=y" >> $config_target_mak >> gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml >> power-spe.xml" >> ;; >> + ppc64el) >> + TARGET_ARCH=ppc64 >> + TARGET_BASE_ARCH=ppc >> + TARGET_ABI_DIR=ppc >> + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml >> power-spe.xml" >> > > I can't see the part where this switches the ABI definition to be little > endian? I'm sure that magic is hidden somewhere, mind to guide me to it? > > > Alex > >
On 05/08/2014 10:46 AM, Doug Kwan (關振德) wrote:
> All the magic happens in the patch 2/3.
Please don't top post.
I still fail to see where you tell the build system that
ppc64le-linux-user should not have TARGET_WORDS_BIGENDIAN set.
Alex
Sorry about missing the question. TARGET_WORDS_BIGENDIAN is not set because of this (around line 4805 in configure): case "$target_name" in armeb|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or32|ppc|ppcemb|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb) target_bigendian=yes The configure script recognizes a list of big-endian target. ppc64le is not one of those. On Thu, May 8, 2014 at 1:56 AM, Alexander Graf <agraf@suse.de> wrote: > On 05/08/2014 10:46 AM, Doug Kwan (關振德) wrote: > >> All the magic happens in the patch 2/3. >> > > Please don't top post. > > I still fail to see where you tell the build system that > ppc64le-linux-user should not have TARGET_WORDS_BIGENDIAN set. > > > Alex > >
Am 08.05.2014 10:26, schrieb Doug Kwan: > Add a new user mode target for little-endian PPC64. > > Signed-off-by: Doug Kwan <dougkwan@google.com> > --- > configure | 6 ++++++ > default-configs/ppc64el-linux-user.mak | 1 + > 2 files changed, 7 insertions(+) > create mode 100644 default-configs/ppc64el-linux-user.mak > > diff --git a/configure b/configure > index ac2fa15..ce44044 100755 > --- a/configure > +++ b/configure > @@ -4917,6 +4917,12 @@ case "$target_name" in > echo "TARGET_ABI32=y" >> $config_target_mak > gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" > ;; > + ppc64el) In SUSE's build system and everywhere I read people talking about it, including your 2/3, it's called ppc64le. Why did you choose ppc64el? Regards, Andreas > + TARGET_ARCH=ppc64 > + TARGET_BASE_ARCH=ppc > + TARGET_ABI_DIR=ppc > + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" > + ;; > sh4|sh4eb) > TARGET_ARCH=sh4 > bflt="yes" > diff --git a/default-configs/ppc64el-linux-user.mak b/default-configs/ppc64el-linux-user.mak > new file mode 100644 > index 0000000..6948225 > --- /dev/null > +++ b/default-configs/ppc64el-linux-user.mak > @@ -0,0 +1 @@ > +# Default configuration for ppc64el-linux-user >
On 8 May 2014 13:18, Andreas Färber <afaerber@suse.de> wrote: > Am 08.05.2014 10:26, schrieb Doug Kwan: >> Add a new user mode target for little-endian PPC64. >> >> Signed-off-by: Doug Kwan <dougkwan@google.com> >> --- >> configure | 6 ++++++ >> default-configs/ppc64el-linux-user.mak | 1 + >> 2 files changed, 7 insertions(+) >> create mode 100644 default-configs/ppc64el-linux-user.mak >> >> diff --git a/configure b/configure >> index ac2fa15..ce44044 100755 >> --- a/configure >> +++ b/configure >> @@ -4917,6 +4917,12 @@ case "$target_name" in >> echo "TARGET_ABI32=y" >> $config_target_mak >> gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" >> ;; >> + ppc64el) > > In SUSE's build system and everywhere I read people talking about it, > including your 2/3, it's called ppc64le. Why did you choose ppc64el? In general we should follow what the kernel does, ie the output of 'uname -m' (which hopefully coincides with the gcc triplet name). What is that for this case? thanks -- PMM
On 05/08/2014 02:28 PM, Peter Maydell wrote: > On 8 May 2014 13:18, Andreas Färber <afaerber@suse.de> wrote: >> Am 08.05.2014 10:26, schrieb Doug Kwan: >>> Add a new user mode target for little-endian PPC64. >>> >>> Signed-off-by: Doug Kwan <dougkwan@google.com> >>> --- >>> configure | 6 ++++++ >>> default-configs/ppc64el-linux-user.mak | 1 + >>> 2 files changed, 7 insertions(+) >>> create mode 100644 default-configs/ppc64el-linux-user.mak >>> >>> diff --git a/configure b/configure >>> index ac2fa15..ce44044 100755 >>> --- a/configure >>> +++ b/configure >>> @@ -4917,6 +4917,12 @@ case "$target_name" in >>> echo "TARGET_ABI32=y" >> $config_target_mak >>> gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" >>> ;; >>> + ppc64el) >> In SUSE's build system and everywhere I read people talking about it, >> including your 2/3, it's called ppc64le. Why did you choose ppc64el? > In general we should follow what the kernel does, ie > the output of 'uname -m' (which hopefully coincides with > the gcc triplet name). What is that for this case? $ uname -a Linux shiraz-1 3.15.0-rc4-2-default+ #22 SMP Wed May 7 22:57:22 CEST 2014 ppc64le ppc64le ppc64le GNU/Linux Thanks a lot for the catch. Just because Debian has it all backwards we don't have to as well ;). Alex
On 5/8/2014 3:26 AM, Doug Kwan wrote: > Add a new user mode target for little-endian PPC64. > > Signed-off-by: Doug Kwan <dougkwan@google.com> > --- > configure | 6 ++++++ > default-configs/ppc64el-linux-user.mak | 1 + > 2 files changed, 7 insertions(+) > create mode 100644 default-configs/ppc64el-linux-user.mak > > diff --git a/configure b/configure > index ac2fa15..ce44044 100755 > --- a/configure > +++ b/configure > @@ -4917,6 +4917,12 @@ case "$target_name" in > echo "TARGET_ABI32=y" >> $config_target_mak > gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" > ;; > + ppc64el) > + TARGET_ARCH=ppc64 > + TARGET_BASE_ARCH=ppc > + TARGET_ABI_DIR=ppc > + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" > + ;; > sh4|sh4eb) > TARGET_ARCH=sh4 > bflt="yes" > diff --git a/default-configs/ppc64el-linux-user.mak b/default-configs/ppc64el-linux-user.mak > new file mode 100644 > index 0000000..6948225 > --- /dev/null > +++ b/default-configs/ppc64el-linux-user.mak > @@ -0,0 +1 @@ > +# Default configuration for ppc64el-linux-user > We have TCG targets for PowerPC that are bi-endian. It would be much nicer to have to split user mode by endianness. If the user loads a BE ELF, then run in BE mode .... a LE ELF, then run in LE mode. I know there is much hand waving in that statement ... but maybe we can do better? ("we" includes "me" in that statement ... since I offered to Doug to help out with this).
On Thu, May 8, 2014 at 7:41 AM, Tom Musta <tommusta@gmail.com> wrote: > On 5/8/2014 3:26 AM, Doug Kwan wrote: > > Add a new user mode target for little-endian PPC64. > > > > Signed-off-by: Doug Kwan <dougkwan@google.com> > > --- > > configure | 6 ++++++ > > default-configs/ppc64el-linux-user.mak | 1 + > > 2 files changed, 7 insertions(+) > > create mode 100644 default-configs/ppc64el-linux-user.mak > > > > diff --git a/configure b/configure > > index ac2fa15..ce44044 100755 > > --- a/configure > > +++ b/configure > > @@ -4917,6 +4917,12 @@ case "$target_name" in > > echo "TARGET_ABI32=y" >> $config_target_mak > > gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml > power-spe.xml" > > ;; > > + ppc64el) > > + TARGET_ARCH=ppc64 > > + TARGET_BASE_ARCH=ppc > > + TARGET_ABI_DIR=ppc > > + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml > power-spe.xml" > > + ;; > > sh4|sh4eb) > > TARGET_ARCH=sh4 > > bflt="yes" > > diff --git a/default-configs/ppc64el-linux-user.mak > b/default-configs/ppc64el-linux-user.mak > > new file mode 100644 > > index 0000000..6948225 > > --- /dev/null > > +++ b/default-configs/ppc64el-linux-user.mak > > @@ -0,0 +1 @@ > > +# Default configuration for ppc64el-linux-user > > > > We have TCG targets for PowerPC that are bi-endian. It would be much nicer > to have to split > user mode by endianness. If the user loads a BE ELF, then run in BE mode > .... a LE ELF, > then run in LE mode. > > I know there is much hand waving in that statement ... but maybe we can do > better? ("we" includes > "me" in that statement ... since I offered to Doug to help out with this). > > > > To do this, we need to fix the elf load. I believe it currently only loads binary the endianness of the same endianness of the configure target. It will be a more general change that will benefit other bi-endian architecture. Would you help me out in that? -Doug
On 8 May 2014 16:19, Doug Kwan (關振德) <dougkwan@google.com> wrote: > On Thu, May 8, 2014 at 7:41 AM, Tom Musta <tommusta@gmail.com> wrote: >> We have TCG targets for PowerPC that are bi-endian. It would be much nicer >> to have to split >> user mode by endianness. If the user loads a BE ELF, then run in BE mode >> .... a LE ELF, >> then run in LE mode. >> >> I know there is much hand waving in that statement ... but maybe we can do >> better? ("we" includes >> "me" in that statement ... since I offered to Doug to help out with this). > To do this, we need to fix the elf load. That is far from the only thing that would need changing. I really don't recommend trying to do something different from the norm here. Isn't LE PPC a different ABI anyway? (ELFv2). thanks -- PMM
On Thu, May 8, 2014 at 8:25 AM, Peter Maydell <peter.maydell@linaro.org>wrote: > On 8 May 2014 16:19, Doug Kwan (關振德) <dougkwan@google.com> wrote: > > On Thu, May 8, 2014 at 7:41 AM, Tom Musta <tommusta@gmail.com> wrote: > >> We have TCG targets for PowerPC that are bi-endian. It would be much > nicer > >> to have to split > >> user mode by endianness. If the user loads a BE ELF, then run in BE > mode > >> .... a LE ELF, > >> then run in LE mode. > >> > >> I know there is much hand waving in that statement ... but maybe we can > do > >> better? ("we" includes > >> "me" in that statement ... since I offered to Doug to help out with > this). > > > To do this, we need to fix the elf load. > > That is far from the only thing that would need changing. > I really don't recommend trying to do something different > from the norm here. > > Isn't LE PPC a different ABI anyway? (ELFv2). > > thanks > -- PMM > What else needs to be fixed? I suspect that the user-mode linux kernel interface may also need some work but it worked well enough in practice for us to build glibc and run gcc testsuite. Yes ELFv2 is a different ABI but it is not complete different from the old one. A notable change is the removal of function descriptor. That affect how the user mode start the first instruction and that is addressed in this set of patches. It would also affect signal handling but user-mode signals do not work at all on PPC64 anyway and the parts that would be affected looks unimplemented.
On 5/8/2014 10:25 AM, Peter Maydell wrote: > On 8 May 2014 16:19, Doug Kwan (關振德) <dougkwan@google.com> wrote: >> On Thu, May 8, 2014 at 7:41 AM, Tom Musta <tommusta@gmail.com> wrote: >>> We have TCG targets for PowerPC that are bi-endian. It would be much nicer >>> to have to split >>> user mode by endianness. If the user loads a BE ELF, then run in BE mode >>> .... a LE ELF, >>> then run in LE mode. >>> >>> I know there is much hand waving in that statement ... but maybe we can do >>> better? ("we" includes >>> "me" in that statement ... since I offered to Doug to help out with this). > >> To do this, we need to fix the elf load. > > That is far from the only thing that would need changing. > I really don't recommend trying to do something different > from the norm here. > > Isn't LE PPC a different ABI anyway? (ELFv2). > > thanks > -- PMM > It is true that the new LE distros are basing on ELFv2. But ELFv2 ABI is not limited to LE. I chatted with Uli on this very topic and he confirmed that endianness is specified in the e_ident field of the header. I believe we have thoroughly demonstrated that the (softmmu) TCG code works correctly in both settings of MSR[LE], without making compile time decisions. It doesn't seem like we are that far off ... maybe I don't see the problem yet.
On 8 May 2014 16:32, Doug Kwan (關振德) <dougkwan@google.com> wrote: > What else needs to be fixed? git grep ENDIAN linux-user is probably a good start on a list. > I suspect that the user-mode linux kernel > interface may also need some work but it worked well enough > in practice for us to build glibc and run gcc testsuite. The gcc testsuite is really not very much of a workout. I recommend getting a chroot environment working and then trying the LTP testsuite: http://wiki.qemu.org/Testing/LTP > Yes ELFv2 is a different ABI but it is not complete different > from the old one. A notable change is the > removal of function descriptor. That affect how the user mode start the > first instruction and that is addressed in this set of patches. It would > also affect signal handling but user-mode signals do not work at all on > PPC64 anyway and the parts that would be affected looks unimplemented. Yes, but we need to actually implement signal handling at some point, so we don't want to end up having to totally redo the base support of ppc64le at that point. The general approach linux-user takes is "one kernel ABI to one QEMU binary". Maybe we could change that, but would there be any benefit to it? I can't really see one. thanks -- PMM
On 8 May 2014 16:39, Tom Musta <tommusta@gmail.com> wrote: > I believe we have thoroughly demonstrated that the (softmmu) > TCG code works correctly in both settings of MSR[LE], without > making compile time decisions. It doesn't seem like we are that > far off ... maybe I don't see the problem yet. Yes, softmmu can and should all work in one TARGET_ENDIAN setting (which corresponds to "endianness of CPU bus", more or less). But linux-user isn't softmmu. thanks -- PMM
On Thu, May 8, 2014 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org>wrote: > On 8 May 2014 16:32, Doug Kwan (關振德) <dougkwan@google.com> wrote: > > What else needs to be fixed? > > git grep ENDIAN linux-user is probably a good start on a list. > > > I suspect that the user-mode linux kernel > > interface may also need some work but it worked well enough > > in practice for us to build glibc and run gcc testsuite. > > The gcc testsuite is really not very much of a workout. > I recommend getting a chroot environment working and then > trying the LTP testsuite: > http://wiki.qemu.org/Testing/LTP > > > Yes ELFv2 is a different ABI but it is not complete different > > from the old one. A notable change is the > > removal of function descriptor. That affect how the user mode start the > > first instruction and that is addressed in this set of patches. It would > > also affect signal handling but user-mode signals do not work at all on > > PPC64 anyway and the parts that would be affected looks unimplemented. > > Yes, but we need to actually implement signal handling at > some point, so we don't want to end up having to totally > redo the base support of ppc64le at that point. > > The general approach linux-user takes is "one kernel > ABI to one QEMU binary". Maybe we could change that, > but would there be any benefit to it? I can't really > see one. > > thanks > -- PMM > May I ask what you would suggest to support ppc64le then? For signal handling, we can check the ELF header to see if we use a function descriptor or an entry for a signal handler when this is implemented for ppc64 in the future. I don't understand the "redoing the base support" bit.
On 8 May 2014 16:51, Doug Kwan (關振德) <dougkwan@google.com> wrote: > On Thu, May 8, 2014 at 8:41 AM, Peter Maydell <peter.maydell@linaro.org> > wrote: >> The general approach linux-user takes is "one kernel >> ABI to one QEMU binary". Maybe we could change that, >> but would there be any benefit to it? I can't really >> see one. > May I ask what you would suggest to support ppc64le then? For signal > handling, we can check the ELF header to see if we use a function descriptor > or an entry for a signal handler when this is implemented for ppc64 in the > future. I don't understand the "redoing the base support" bit. Do it the same way we support everything else that can deal with two endianness settings -- handle the other TARGET_ENDIAN case in the translator. This is pretty straightforward with the new TCGMemOp TCG ops. thanks -- PMM
On Thu, May 8, 2014 at 5:28 AM, Peter Maydell <peter.maydell@linaro.org>wrote: > On 8 May 2014 13:18, Andreas Färber <afaerber@suse.de> wrote: > > Am 08.05.2014 10:26, schrieb Doug Kwan: > >> Add a new user mode target for little-endian PPC64. > >> > >> Signed-off-by: Doug Kwan <dougkwan@google.com> > >> --- > >> configure | 6 ++++++ > >> default-configs/ppc64el-linux-user.mak | 1 + > >> 2 files changed, 7 insertions(+) > >> create mode 100644 default-configs/ppc64el-linux-user.mak > >> > >> diff --git a/configure b/configure > >> index ac2fa15..ce44044 100755 > >> --- a/configure > >> +++ b/configure > >> @@ -4917,6 +4917,12 @@ case "$target_name" in > >> echo "TARGET_ABI32=y" >> $config_target_mak > >> gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml > power-spe.xml" > >> ;; > >> + ppc64el) > > > > In SUSE's build system and everywhere I read people talking about it, > > including your 2/3, it's called ppc64le. Why did you choose ppc64el? > > In general we should follow what the kernel does, ie > the output of 'uname -m' (which hopefully coincides with > the gcc triplet name). What is that for this case? > > thanks > -- PMM > I am aware of the 'le' vs 'el' issue. However, I saw that all bi-endian targets have 'el' or 'eb' suffixes (e.g. mipsel-linux-user). So I thought qemu follows the Debian convention. I will fix that. Thanks.
diff --git a/configure b/configure index ac2fa15..ce44044 100755 --- a/configure +++ b/configure @@ -4917,6 +4917,12 @@ case "$target_name" in echo "TARGET_ABI32=y" >> $config_target_mak gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" ;; + ppc64el) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml" + ;; sh4|sh4eb) TARGET_ARCH=sh4 bflt="yes" diff --git a/default-configs/ppc64el-linux-user.mak b/default-configs/ppc64el-linux-user.mak new file mode 100644 index 0000000..6948225 --- /dev/null +++ b/default-configs/ppc64el-linux-user.mak @@ -0,0 +1 @@ +# Default configuration for ppc64el-linux-user
Add a new user mode target for little-endian PPC64. Signed-off-by: Doug Kwan <dougkwan@google.com> --- configure | 6 ++++++ default-configs/ppc64el-linux-user.mak | 1 + 2 files changed, 7 insertions(+) create mode 100644 default-configs/ppc64el-linux-user.mak