PR65416, alloca on xtensa
Hi Sterling, I've got an issue building gdb for xtensa linux with gcc, reported it here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416 Looking at it I've got two questions, can you help me with them? 1. in windowed ABI stack pointer update is always split into two opcodes: add and movsp. How gcc optimization passes are supposed to know that 'movsp' is related to 'add' and that stack allocation is complete only after movsp? 2. alloca seems to make an additional 16-bytes padding to each stack allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17) moves it by 48 bytes, etc. This padding looks unnecessary to me: either this space is not used (previous register frame is not spilled), or alloca exception handler will take care about reloading or moving spilled registers to a new location. In both cases after movsp this space is just wasted. Do you know why this padding may be needed? -- Thanks. -- Max
Re: PR65416, alloca on xtensa
On Fri, Mar 13, 2015 at 8:08 PM, augustine.sterl...@gmail.com wrote: > On Fri, Mar 13, 2015 at 10:04 AM, Marc Gauthier wrote: >> Other than the required 16-byte stack alignment, there's nothing in >> the ABI that requires these extra 16 bytes. Perhaps there was a bad >> implementation of the alloca exception handler at some point a long >> time ago that prompted the extra 16 bytes? > > The alloca handler has been rewritten at least twice since this code > was last updated, so that wouldn't surprise me at all. I would approve > a change to eliminate it. Ok, thanks to both of you. I'll try to come up with fixes. -- Thanks. -- Max
Re: PR65416, alloca on xtensa
On Fri, Mar 13, 2015 at 11:18 PM, Segher Boessenkool wrote: > On Fri, Mar 13, 2015 at 05:54:48PM +0300, Max Filippov wrote: >> 2. alloca seems to make an additional 16-bytes padding to each stack >> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17) >> moves it by 48 bytes, etc. > > This sounds like PR 50938, 47353, 34548, maybe more? Happens on most > targets. Exactly! (And I was wrong about 1 byte, it needs at least 2 for 32 bytes result). But...those PRs are marked as duplicates of a fixed PR 34548. Looks like it's not fixed or there's a regression? -- Thanks. -- Max
Re: xtensa PR65730
On Fri, Apr 10, 2015 at 10:51 PM, augustine.sterl...@gmail.com
wrote:
> On Fri, Apr 10, 2015 at 12:15 PM, Max Filippov wrote:
>> Then configuration w/o multiplication should call helper at -O0 and
>> use shift at higher optimization levels?
>
> That is what I would expect.
Ok, then I see why this doesn't happen: mulsi3 pattern matching is
conditional on TARGET_MUL32, so when TARGET_MUL32 ==0 and
expand_simple_binop emits a call to a helper it's not considered
mulsi3, it's just a call:
(call_insn/u 17 15 18 3 (set (reg:SI 10 a10)
(call (mem:SI (reg:SI 56) [0 S4 A32])
(const_int 0 [0])))
libstdc++-v3/include/bits/atomic_base.h:287 51 {call_value_internal}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("__mulsi3") [flags 0x41])
(expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil)))
(expr_list (use (reg:SI 11 a11))
(expr_list (use (reg:SI 10 a10))
(nil
vs.
(insn 15 14 16 3 (set (reg:SI 57)
(mult:SI (reg:SI 55)
(reg:SI 56))) libstdc++-v3/include/bits/atomic_base.h:287 5 {mulsi3}
(nil))
How can we have a mulsi3 pattern that don't get expanded until it's
optimized, and only gets expanded to a call if it couldn't be optimized?
--
Thanks.
-- Max
Re: xtensa PR65730
On Sat, Apr 11, 2015 at 2:16 AM, augustine.sterl...@gmail.com wrote: > On Fri, Apr 10, 2015 at 1:18 PM, Max Filippov wrote: >> How can we have a mulsi3 pattern that don't get expanded until it's >> optimized, and only gets expanded to a call if it couldn't be optimized? > > I'm not completely sure, but I think you want to use OPTAB_LIB as you > described above, and eliminate the TARGET_MUL32 condition in the > pattern. In that case mull is emitted for normal uses of multiplication. -- Thanks. -- Max
Re: why do we need xtensa-config.h?
Hello, On Tue, Sep 6, 2016 at 11:42 AM, Oleksij Rempel wrote: > i'm one of ath9k-htc-firmware developers. Currently i'm looking for the > way to provide this firmware as opensource/free package for debian. Main > problem seems to be the need to patch gcc xtensa-config.h to make it > suitable for our CPU. > > I have fallowing questions: > > do we really need this patch? > https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch Yes, these changes are needed, but perhaps not in a form of a patch. The changed file is a part of the configuration overlay that need to be applied to binutils, gcc and gdb in order to configure them to generate code for the specific xtensa core. We have xtensa support in the crosstool-NG and the Buildroot, both of which can generate xtensa toolchain using configuration overlay. Please refer to http://wiki.linux-xtensa.org/index.php/Toolchain_and_Embedded_Distributions for more information about xtensa configuration overlay and its usage by crosstool-NG and Buildroot. > Is it possible or welcome to extend gcc to be configurable without > patching it all the time? It is definitely welcome and is likely possible. Please do not forget that both gcc and binutils need to have coherent idea of the processor they're generating code for. -- Thanks. -- Max
Re: how to build and test uClinux toolchains
On Wed, Oct 31, 2018 at 8:43 AM Christophe Lyon wrote: > I also built qemu from the branch you mentioned, > and used the "run it on linux-user QEMU" section in the wiki > > I see many execution errors, now realizing that I didn't > do what you said above: "apply gcc part of the xtensa overlay". > But what is this? It's a set of files that must be replaced in the toolchain source to configure it for a specific xtensa core. For gcc the config that you've built changes single file, include/xtensa-config.h and the change is the following: --8<-- diff --git a/include/xtensa-config.h b/include/xtensa-config.h index d6713d23a6b2..18899f827ea7 100644 --- a/include/xtensa-config.h +++ b/include/xtensa-config.h @@ -25,7 +25,7 @@ macros. */ #undef XCHAL_HAVE_BE -#define XCHAL_HAVE_BE 1 +#define XCHAL_HAVE_BE 0 #undef XCHAL_HAVE_DENSITY #define XCHAL_HAVE_DENSITY 1 -->8-- > And while writing this reply, I'm just realizing that buildroot builds > for uclinux-uclibc-gcc, while the wiki uses linux-uclibc :( > Does the wiki need an update wrt target name? Yeah, I used it as an example. Let me update it so that it works for uclinux without obscure modifications. I was able to figure out why C++ exceptions didn't work: because the target code was built as PIC by default and it's not supported by the bFLT file format. I've posted a fix here: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00286.html -- Thanks. -- Max
Re: how to build and test uClinux toolchains
On Fri, Nov 2, 2018 at 3:29 AM Christophe Lyon wrote: > I re-ran the wiki instructions with --target=xtensa-buildroot-uclinux-uclibc > and while gcc/g++ results looks mostly OK, the libstdc++ ones only show: > Running ...f/trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... > ERROR: could not compile testsuite_abi.cc > ERROR: tcl error > sourcing.../trunk/libstdc++-v3/testsuite/libstdc++-abi/abi.exp. > Running.../trunk/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... > ERROR: could not compile testsuite_abi.cc > etc... > > libstdc++.log show many instances of: > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function > 'symbols create_symbols(const char*)':^M > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:565: note: > non-delegitimized UNSPEC 3 found in variable location^M > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc: In function > 'void examine_symbol(const char*, const char*)':^M > .../trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc:355: note: > non-delegitimized UNSPEC 3 found in variable location^M "non-delegitimized UNSPEC 3 found" is a note, not an error. There should also be an error. > Do you know what the problem is in my setup? Or with GCC trunk? I ran make check on gcc trunk from 2018-10-20, libstdc++ testsuite works for me: === libstdc++ Summary === # of expected passes9889 # of unexpected failures89 # of unexpected successes 4 # of expected failures 79 # of unresolved testcases 17 # of unsupported tests 758 -- Thanks. -- Max
[RFC] moving assemble_start_function / assemble_end_function to output_mi_thunk
Hello, I'm implementing MI thunk generation for the xtensa target and I've got an issue that when my code generates a constant it is missing in the resulting assembly. This happens because a constant pool output happens inside the assemble_start_function, which is called before the thunk function body has a chance to be generated. The following patch moves assemble_start_function / assemble_end_function pair to the backend for all targets that define TARGET_ASM_OUTPUT_MI_THUNK to allow calling assemble_start_function after the function body is ready. Is it OK, or should I try to fix it differently? ---8<--- >From bad901880a3f9fc69726aa082e2b2c674bacca94 Mon Sep 17 00:00:00 2001 From: Max Filippov Date: Mon, 7 Jan 2019 18:22:12 -0800 Subject: [PATCH] gcc: move assemble_start_function / assemble_end_function to output_mi_thunk Let backends call assemble_start_function after they have generated thunk function body so that a constant pool could be output if it is required. gcc/ 2019-01-08 Max Filippov * cgraphunit.c (cgraph_node::expand_thunk): Remove assemble_start_function and assemble_end_function calls. * config/alpha/alpha.c (alpha_output_mi_thunk_osf): Call assemble_start_function and assemble_end_function. * config/arc/arc.c (arc_output_mi_thunk): Likewise. * config/arm/arm.c (arm_output_mi_thunk): Likewise. * config/bfin/bfin.c (bfin_output_mi_thunk): Likewise. * config/c6x/c6x.c (c6x_output_mi_thunk): Likewise. * config/cris/cris.c (cris_asm_output_mi_thunk): Likewise. * config/csky/csky.c (csky_output_mi_thunk): Likewise. * config/epiphany/epiphany.c (epiphany_output_mi_thunk): Likewise. * config/frv/frv.c (frv_asm_output_mi_thunk): Likewise. * config/i386/i386.c (x86_output_mi_thunk): Likewise. * config/ia64/ia64.c (ia64_output_mi_thunk): Likewise. * config/m68k/m68k.c (m68k_output_mi_thunk): Likewise. * config/microblaze/microblaze.c (microblaze_asm_output_mi_thunk): Likewise. * config/mips/mips.c (mips_output_mi_thunk): Likewise. * config/mmix/mmix.c (mmix_asm_output_mi_thunk): Likewise. * config/mn10300/mn10300.c (mn10300_asm_output_mi_thunk): Likewise. * config/nds32/nds32.c (nds32_asm_output_mi_thunk): Likewise. * config/nios2/nios2.c (nios2_asm_output_mi_thunk): Likewise. * config/or1k/or1k.c (or1k_output_mi_thunk): Likewise. * config/pa/pa.c (pa_asm_output_mi_thunk): Likewise. * config/riscv/riscv.c (riscv_output_mi_thunk): Likewise. * config/rs6000/rs6000.c (rs6000_output_mi_thunk): Likewise. * config/s390/s390.c (s390_output_mi_thunk): Likewise. * config/sh/sh.c (sh_output_mi_thunk): Likewise. * config/sparc/sparc.c (sparc_output_mi_thunk): Likewise. * config/spu/spu.c (spu_output_mi_thunk): Likewise. * config/stormy16/stormy16.c (xstormy16_asm_output_mi_thunk): Likewise. * config/tilegx/tilegx.c (tilegx_output_mi_thunk): Likewise. * config/tilepro/tilepro.c (tilepro_asm_output_mi_thunk): Likewise. * config/vax/vax.c (vax_output_mi_thunk): Likewise. --- gcc/cgraphunit.c | 4 gcc/config/alpha/alpha.c | 3 +++ gcc/config/arc/arc.c | 4 gcc/config/arm/arm.c | 4 gcc/config/bfin/bfin.c | 3 +++ gcc/config/c6x/c6x.c | 3 +++ gcc/config/cris/cris.c | 4 gcc/config/csky/csky.c | 3 +++ gcc/config/epiphany/epiphany.c | 3 +++ gcc/config/frv/frv.c | 4 gcc/config/i386/i386.c | 5 - gcc/config/ia64/ia64.c | 3 +++ gcc/config/m68k/m68k.c | 3 +++ gcc/config/microblaze/microblaze.c | 3 +++ gcc/config/mips/mips.c | 3 +++ gcc/config/mmix/mmix.c | 6 +- gcc/config/mn10300/mn10300.c | 3 +++ gcc/config/nds32/nds32.c | 3 +++ gcc/config/nios2/nios2.c | 3 +++ gcc/config/or1k/or1k.c | 5 - gcc/config/pa/pa.c | 3 +++ gcc/config/riscv/riscv.c | 3 +++ gcc/config/rs6000/rs6000.c | 3 +++ gcc/config/s390/s390.c | 3 +++ gcc/config/sh/sh.c | 3 +++ gcc/config/sparc/sparc.c | 3 +++ gcc/config/spu/spu.c | 3 +++ gcc/config/stormy16/stormy16.c | 3 +++ gcc/config/tilegx/tilegx.c | 3 +++ gcc/config/tilepro/tilepro.c | 3 +++ gcc/config/vax/vax.c | 4 31 files changed, 99 insertions(+), 7 deletions(-) diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c index e6b1296abfb5..1c070ee95cd7 100644 --- a/gcc/cgraphunit.c +++ b/gcc/cgraphunit.c @@ -1786,7 +1786,6 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk) && targetm.asm_out.can_output_mi_thunk (th
backporting fixes for xtensa to stable branches
Hi Sterling,
for xtensa we have a number of bugfixes in the mainline that were never
backported to the stable branches. It'd be great having them in the stable
gcc releases instead of carrying the fixes in various toolchain builders.
Would it be ok to do the following backports?
to the gcc-5-branch:
r226963 ("xtensa: use unwind-dw2-fde-dip instead of unwind-dw2-fde"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=226963
r226964 ("xtensa: fix _Unwind_GetCFA"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=226964
r227809 ("xtensa: fix xtensa_fallback_frame_state for call0 ABI"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227809
r233505 ("xtensa: fix libgcc build with --text-section-literals"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=233505
r241313 ("xtensa: don't use unwind-dw2-fde-dip with elf targets"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=241313
r242979 ("xtensa: Fix PR target/78603"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242979
r248586 ("gcc: xtensa: fix fprintf format specifiers"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248586
to the gcc-6-branch:
r241313 ("xtensa: don't use unwind-dw2-fde-dip with elf targets"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=241313
r241748 ("xtensa: Fix PR target/78118"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=241748
r242979 ("xtensa: Fix PR target/78603"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242979
r248586 ("gcc: xtensa: fix fprintf format specifiers"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248586
to the gcc-7-branch:
r248586 ("gcc: xtensa: fix fprintf format specifiers"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=248586
--
Thanks.
-- Max
Re: backporting fixes for xtensa to stable branches
On Tue, May 30, 2017 at 3:34 PM, augustine.sterl...@gmail.com wrote: > On Tue, May 30, 2017 at 3:26 PM, Max Filippov wrote: >> Hi Sterling, >> >> for xtensa we have a number of bugfixes in the mainline that were never >> backported to the stable branches. It'd be great having them in the stable >> gcc releases instead of carrying the fixes in various toolchain builders. >> Would it be ok to do the following backports? > > Yes. All backports are absolutely fine. Thanks. Applied all mentioned patches to the corresponding branches. -- Max
CFLAGS for the host in canadian cross build
Hello, I'm trying to build a canadian cross compiler with build == x86_64-linux, host == xtensa-linux and target == xtensa-linux. I need to specify an xtensa-specific flag in CFLAGS that will be applied to the host binary. I put this flag into CFLAGS and CXXFLAGS. The first question: is that the right place for it? The build process tries to build libcpp for the build system and it runs x86_64 gcc with that xtensa-specific option. That's where the build breaks for me, because the option is not recognized by the build gcc. Is it supposed to work? If CFLAGS/CXXFLAGS is the right place for the option, how can the build tell whether it's intended for the build or for the host? -- Thanks. -- Max
Re: CFLAGS for the host in canadian cross build
On Mon, Nov 6, 2017 at 10:38 AM, Matias Fonzo wrote: > On Mon, 6 Nov 2017 10:30:14 -0800 > Max Filippov wrote: > >> Hello, >> >> I'm trying to build a canadian cross compiler with build == >> x86_64-linux, host == xtensa-linux and target == xtensa-linux. I need >> to specify an xtensa-specific flag in CFLAGS that will be applied to >> the host binary. >> >> I put this flag into CFLAGS and CXXFLAGS. The first question: is that >> the right place for it? >> >> The build process tries to build libcpp for the build system and it >> runs x86_64 gcc with that xtensa-specific option. That's where the >> build breaks for me, because the option is not recognized by the >> build gcc. Is it supposed to work? >> >> If CFLAGS/CXXFLAGS is the right place for the option, how can the >> build tell whether it's intended for the build or for the host? > > GCC has $CFLAGS_FOR_BUILD and $CFLAGS_FOR_TARGET. Right, but as far as I can see CFLAGS_FOR_TARGET are not applied when a binary for the host is built. And CFLAGS_FOR_BUILD are applied when a binary for the build system is built. I don't see what I'd call CFLAGS_FOR_HOST. -- Thanks. -- Max
Re: CFLAGS for the host in canadian cross build
Hi Waldemar, On Tue, Nov 7, 2017 at 9:57 PM, Waldemar Brodkorb wrote: >> I'm trying to build a canadian cross compiler with build == x86_64-linux, >> host == xtensa-linux and target == xtensa-linux. I need to specify an >> xtensa-specific flag in CFLAGS that will be applied to the host binary. > > I think you are trying to build a cross-native, see > http://crosstool-ng.github.io/docs/toolchain-types/ > > Canadian-Cross is something like building a GCC compiler on Linux/x86_64, > which runs on Cygwin/x86_64 and compiles code for Linux/ppc. Yes, I just thought that "cross-native" is the local ct-ng name, and in general this configuration is not special. >> I put this flag into CFLAGS and CXXFLAGS. The first question: is that >> the right place for it? > > No, it seems not. > The right thing to do is to set CC/CXX in the configure step and > append your specific CFLAGS/CXXFLAGS to it. Ok, thanks for the confirmation. I did the same thing by making a wrapper that calls cross-compiler with these specific options. Using that I was able to build working cross-native toolchain with ct-ng. -- Thanks. -- Max
Re: why C++ cannot alias an inline function, C can ?
On Sun, Apr 1, 2018 at 4:34 AM, Jason Vas Dias wrote:
> In C++ however, it does not compile :
>
> $ g++ -g -std=gnu++11 -x c++ -c t.c
> t.c:5:8: error: 'void bar()' aliased to undefined symbol 'foo'
>void bar(void);
> ^
>
> Even though, if I compile the object with the declaration
> of bar() commented out , I can see C++ is not mangling
> the name "foo" :
gcc manual says the follwing about the alias attribute:
"In C++, the mangled name for the target must be used."
so with the following modification your example compiles:
static inline __attribute__((always_inline,alias("_ZL3foov")))
void bar(void);
--
Thanks.
-- Max
Re: why C++ cannot alias an inline function, C can ?
On Sun, Apr 1, 2018 at 5:33 AM, Jason Vas Dias wrote:
> Aha! But how to determine the mangled name beforehand ?
>
> Even if I compile the object without the alias, then inspect
> the object with objdump, there is no mangled symbol
> _ZL3foov defined in the object file .
>
> So I must run some name mangler / generator as a
> pre-processing step to get the correct mangled name
> string ?
I guess so. Or you could define foo with C linkage:
extern "C" {
static inline __attribute__((always_inline))
void foo(void){}
};
static inline __attribute__((always_inline,alias("foo")))
void bar(void);
static
void f(void) { foo(); }
// must have a usage to generate any code
> I think it is unacceptable to be forced to used
> mangled symbol names for objects which are
> not symbols (pure inline functions) .
Pure inline functions may be overloaded, how will you
decide which one to alias given only unmangled name?
--
Thanks.
-- Max
Re: how to build and test uClinux toolchains
Hello, On Tue, Oct 16, 2018 at 1:54 PM Jim Wilson wrote: > > On 10/16/18 7:19 AM, Christophe Lyon wrote: > > While reviewing one of my patches about FDPIC support for ARM, Richard > > raised the concern of testing the patch on other uClinux targets [1]. > > > > I looked at uclinux.org and at the GCC maintainers file, but it's > > still not obvious to me which uClinux targets are currently supported? I'm trying to keep nommu xtensa alive. > I see that buildroot has obvious blackfin (bfin), m68k, and xtensa > uclinux support. But blackfin.uclinux.org says the uclinux port was > deprecated in 2012. m68k as mentioned above should be usable. It > appears that xtensa uclinux is still alive and usable. > http://wiki.linux-xtensa.org/index.php/UClinux Probably the easiest way to get all xtensa toolchain parts correctly it by using existing buildroot configuration. E.g. the following configuration may be used to build uclinux xtensa toolchain for the dc233c core: https://git.buildroot.net/buildroot/tree/configs/qemu_xtensa_lx60_nommu_defconfig Also bFLT executable format is currently not supported for linux-user xtensa QEMU. The following branch adds that support: https://github.com/OSLL/qemu-xtensa/commits/xtensa-bflt qemu-xtensa built from this QEMU then may be registered as a binfmt handler for bFLT executable images allowing to run gcc tests that want to run target binaries. -- Thanks. -- Max
Re: how to build and test uClinux toolchains
On Fri, Oct 26, 2018 at 6:51 AM Christophe Lyon wrote: > On Sun, 21 Oct 2018 at 04:06, Max Filippov wrote: > > Probably the easiest way to get all xtensa toolchain parts correctly it > > by using existing buildroot configuration. E.g. the following configuration > > may be used to build uclinux xtensa toolchain for the dc233c core: > > https://git.buildroot.net/buildroot/tree/configs/qemu_xtensa_lx60_nommu_defconfig > > > OK, thanks for your suggestion. I think I managed to build it. > Now, how/where can I run 'make check' for gcc? > I do not see the GCC build tree. The gcc build tree is usually in the build/host-gcc-final in the buildroot build tree. But that's gcc version selected in the buildroot, you probably want a different version. Usually after the buildroot toolchain is ready I build gcc separately using binutils and sysroot produced by the buildroot. I have a few examples here: http://wiki.osll.ru/doku.php/etc:users:jcmvbkbc:gcc-xtensa-call0 Please note that you'd need to apply gcc part of the xtensa overlay to your gcc source for it to correctly generate code for that configuration. I've run the tests with the current gcc trunk and a lot of execution tests related to TLS (which is expected) and exceptions (which I didn't expect) are failing. I'm looking at it. > > Also bFLT executable format is currently not supported for linux-user > > xtensa QEMU. The following branch adds that support: > > https://github.com/OSLL/qemu-xtensa/commits/xtensa-bflt > > > > qemu-xtensa built from this QEMU then may be registered as a binfmt > > handler for bFLT executable images allowing to run gcc tests that want > > to run target binaries. > Do you have the magic commands for this? If you build QEMU from the link above you can use the following command to register binfmt handler for bFLT binaries assuming that you've installed it into $QEMU_PREFIX: sudo scripts/qemu-binfmt-conf.sh --qemu-path=$QEMU_PREFIX/bin --flat 'xtensa' The --flat switch is not final, it will likely change before it's accepted to the QEMU mainline. -- Thanks. -- Max
Re: Transitioning to a new Xtensa Port Maintainer
Hi Alan, On Thu, May 28, 2020 at 7:53 PM Alan Modra via Gcc wrote: > > On Thu, May 28, 2020 at 10:12:04AM -0700, augustine.sterling--- via Gcc wrote: > > After a long run as the Xtensa port maintainer, it is time for me to move > > on. > > > > I nominate Max Filippov [cc'd] as the new maintainer. He has contributed > > numerous patches over the years which have required minimal comments from > > me. > > Sign him up by adding his name in binutils/MAINTAINERS. > > > If there is anything I need to do to facilitate this, let me know. I'm > > happy to still review patches when needed. > > That sounds like you're not abandoning binutils entirely, so you could > simply leave your name in binutils/MAINTAINERS where it is but put Max > on the line before your entry. I've committed this change to binutils/MAINTAINERS. -- Thanks. -- Max
Re: Max Filippov appointed Xtensa maintainer
On Fri, Jun 5, 2020 at 5:50 PM David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Max Filippov as Xtensa maintainer. Thank you for your trust. > Please join me in congratulating Max on his new role. > Max, please update your listing in the MAINTAINERS file. Updated as follows: 2020-06-06 Max Filippov * MAINTAINERS: Add myself as xtensa port maintainer. --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5528aad5e232..d1343d33f1ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -118,6 +118,7 @@ visium portEric Botcazou x86-64 portJan Hubicka xstormy16 portNick Clifton xtensa portSterling Augustine +xtensa portMax Filippov OS Port Maintainers(OS alphabetical order) @@ -383,7 +384,6 @@ Chris Fairles Alessandro Fanfarillo Changpeng Fang Li Feng -Max Filippov Thomas Fitzsimmons Alexander Fomin Brian Ford -- Thanks. -- Max
Re: out-of-bounds heap access in IRA
On Mon, Oct 31, 2022 at 1:23 PM Max Filippov wrote: > I've been playing with a cross-compiler built with ASAN for > target=xtensa-linux-uclibc and I was consistently getting a > report for out-of-bound heap access inside IRA. I'll file a bug report. -- Thanks. -- Max
unneeded spills of SF values on xtensa with FPU
Hi Suwa-san,
I've noticed that in xtensa configurations with hardware FPU
function arguments of type float are spilled on the stack although
there's no need for that. E.g. the following function:
int f(float a, float b)
{
return a < b;
}
translates to the following with -O2:
f:
entry sp, 48
wfr f0, a2
wfr f1, a3
s32i.n a2, sp, 0
olt.s b0, f0, f1
movi.n a8, 0
movi.n a2, 1
s32i.n a3, sp, 4
movfa2, a8, b0
retw.n
The relevant RTL looks like this at the end of IRA:
(insn 18 4 19 2 (set (reg:SF 51)
(reg:SF 2 a2 [ a ])) "test2.c":2:1 61 {movsf_internal}
(expr_list:REG_DEAD (reg:SF 2 a2 [ a ])
(nil)))
(insn 19 18 7 2 (set (reg:SF 52)
(reg:SF 3 a3 [ b ])) "test2.c":2:1 61 {movsf_internal}
(expr_list:REG_DEAD (reg:SF 3 a3 [ b ])
(nil)))
(insn 7 19 21 2 (set (reg:CC 18 b0)
(lt:CC (reg:SF 51)
(reg:SF 52))) "test2.c":3:11 100 {slt_sf}
(expr_list:REG_DEAD (reg:SF 52)
(expr_list:REG_DEAD (reg:SF 51)
(nil
and it is transformed to the following by the end of LRA:
(insn 18 4 19 2 (set (mem/c:SF (reg/f:SI 1 sp) [1 %sfp+0 S4 A32])
(reg:SF 2 a2 [ a ])) "test2.c":2:1 61 {movsf_internal}
(nil))
(insn 19 18 24 2 (set (mem/c:SF (plus:SI (reg/f:SI 1 sp)
(const_int 4 [0x4])) [1 %sfp+4 S4 A32])
(reg:SF 3 a3 [ b ])) "test2.c":2:1 61 {movsf_internal}
(nil))
(insn 24 19 25 2 (set (reg:SF 19 f0 [51])
(mem/c:SF (reg/f:SI 1 sp) [1 %sfp+0 S4 A32])) "test2.c":3:11 61
{movsf_internal}
(nil))
(insn 25 24 7 2 (set (reg:SF 20 f1 [52])
(mem/c:SF (plus:SI (reg/f:SI 1 sp)
(const_int 4 [0x4])) [1 %sfp+4 S4 A32])) "test2.c":3:11
61 {movsf_internal}
(nil))
(insn 7 25 21 2 (set (reg:CC 18 b0)
(lt:CC (reg:SF 19 f0 [51])
(reg:SF 20 f1 [52]))) "test2.c":3:11 100 {slt_sf}
(nil))
LRA stops checking alternatives for insns 18 and 19 at s32i.n,
but even if I move wfr at the head of the movsf_internal list it
still loses to s32i.n.
Postreload pass replaces the lsi instructions 24 and 25 with
wfr from a2 and a3, but doesn't remove the spills.
I wonder what can be done with that?
--
Thanks.
-- Max
[RFC] Draft Xtensa FDPIC ABI
Hello. This is a draft FDPIC ABI specification for the Xtensa architecture. Please send comments. I will be implementing the final ABI version in gcc and binutils. The Xtensa FDPIC ABI April 8, 2024 Version 1 Based on SH FDPIC ABI Version 1.0 by Joseph Myers. Based on FR-V FDPIC ABI Version 1.0a by Kevin Buettner, Alexandre Oliva and Richard Henderson. Introduction This document describes extensions to the existing Xtensa ELF ABI (as used on GNU/Linux) required to support the implementation of shared libraries on a system whose OS (and hardware) require that processes share a common address space. This document will also attempt to explore the motivations behind and the implications of these extensions. One of the primary goals in using shared libraries is to reduce the memory requirements of the overall system. Thus, if two processes use the same library, the hope is that at least some of the memory pages will be shared between the two processes resulting in an overall savings. To realize these savings, tools used to build a program and library must identify which sections may be shared and which must not be shared. The shared sections, when grouped together, are commonly referred to as the "text segment" whereas the non-shared (grouped) sections are commonly referred to as the "data segment". The text segment is read-only and is usually comprised of executable code and read-only data. The data segment must be writable and it is this fact which makes it non-sharable. Systems which utilize disjoint address spaces for its processes are free to group the text and data segments in such a way that they may always be loaded with fixed relative positions of the text and data segments. I.e, for a given load object, the offset from the start of the text segment to the start of the data segment is constant. This property greatly simplifies the design of the shared library machinery. The design of the shared library mechanism described in this document does not (and cannot) have this property. Due to the fact that all processes share a common address space, the text and data segments will be placed at arbitrary locations relative to each other and will therefore need a mechanism whereby executable code will always be able to find its corresponding data. One of the CPU's registers is typically dedicated to hold the base address of the data segment. This register will be called the "FDPIC register" in this document. Such a register is sometimes used in systems with disjoint address spaces too, but this is for efficiency rather than necessity. The fact that the locations of the text and data segments are at non-constant offsets with respect to each other also complicates function pointer representation. As noted above, executable code must be able to find its corresponding data segment. When making an indirect function call, it is therefore important that both the address of the function and the base address of the data segment are available. This means that a function pointer needs to represented as the address of a "function descriptor" which contains the address of the actual code to execute as well as the corresponding data (FDPIC register) address. FDPIC Register -- The FDPIC register is used as a base register for accessing the global offset table (GOT) and function descriptors. Since both code and data are relocatable, executable code may not contain any instruction sequences which directly encode a pointer's value. Instead, pointers to global data are indirectly referenced via the global offset table. At load time, pointers contained in the global offset table are relocated by the dynamic linker to point at the correct locations. This FDPIC ABI is defined as extension of the base call0 Xtensa ABI. Register a11 is used as the FDPIC register. Version of the FDPIC ABI based on windowed Xtensa ABI is not defined in this document revision. Upon entry to a function, the caller saved register a11 is the FDPIC register. As described above, it contains the GOT address for that function. a11 obtains its value in one of the following ways: 1) By being inherited from the calling function in the case of a direct call to a function within the same load module. 2) By being set from a function descriptor as part of a direct or an indirect call. The specifics associated with each of these cases are covered in greater detail in "Function Calls", below. A non-leaf function should save a11 either on the stack or in one of the callee-saved registers if it needs to use it later. After that there's no requirement to preserve the original a11 value, that register does not have any special meaning inside the function. Note that once a function has moved a11 to one of its callee saved registers, the function is then free to use that register as the FDPIC register for acc
