Re: How to configure a bi-arch PowerPC GCC?
On 21/01/17 01:46, Segher Boessenkool wrote: On Fri, Jan 20, 2017 at 08:35:14AM +0100, Sebastian Huber wrote: so you seem to have 64-bit ABI_V4? I wonder how well tested that is, you are likely to run into more problems. Either stack_restore_tie or the above code will need a tweak. thanks for your help. I would had a hard time to figure this out myself. I am flexible in terms of the ABI choice for the 64-bit PowerPC. I guess the ABI_ELFv2 is the way to go? It certainly is the most modern ABI. It makes some requirements to what Power ISA features are required, which may or may not be a problem for your platform. If you want to use BE, that should work with ELFv2 fine (and it did in the past at least), but it doesn't get serious testing. I use now the attached patch and get the following error types (for several multilibs): /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/powerpc-rtems4.12/bin/ -B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem /opt/rtems-4.12/powerpc-rtems4.12/include -isystem /opt/rtems-4.12/powerpc-rtems4.12/sys-include-g -O2 -mcpu=8540 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o ibm-ldouble.o -MT ibm-ldouble.o -MD -MP -MF ibm-ldouble.dep -c /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c -fvisibility=hidden -DHIDE_EXPORTS # the right startup files when linking shared libgcc. /bin/sh /home/EB/sebastian_h/archive/gcc-git/libgcc/../mkinstalldirs ../../.././gcc/m8540 parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"; \ for file in $parts; do \ rm -f ../../.././gcc/m8540/$file; \ /usr/bin/install -c -m 644 $file ../../.././gcc/m8540/; \ case $file in \ *.a)\ /opt/rtems-4.12/powerpc-rtems4.12/bin/ranlib ../../.././gcc/m8540/$file ;;\ esac; \ done In file included from /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:374:0: /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:72:1: error: unable to emulate 'TF' typedef float TFtype __attribute__ ((mode (TF))); ^~~ config.status: creating auto-target.h config.status: auto-target.h is unchanged config.status: executing default commands In file included from /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/soft-fp.h:321:0, from /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:372: /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c: In function 'fmsub': /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/op-common.h:900:10: warning: this statement may fall through [-Wimplicit-fallthrough=] R##_s = X##_s; \ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:182:29: note: in expansion of macro '_FP_MUL' # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 4, R, X, Y) ^~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:417:5: note: in expansion of macro 'FP_MUL_Q' FP_MUL_Q(U,X,Y); ^~~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/op-common.h:902:2: note: here case _FP_CLS_COMBINE (FP_CLS_INF, FP_CLS_INF): \ ^ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:182:29: note: in expansion of macro '_FP_MUL' # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 4, R, X, Y) ^~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:417:5: note: in expansion of macro 'FP_MUL_Q' FP_MUL_Q(U,X,Y); ^~~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/op-common.h:913:10: warning: this statement may fall through [-Wimplicit-fallthrough=] R##_s = Y##_s; \ /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:182:29: note: in expansion of macro '_FP_MUL' # define FP_MUL_Q(R, X, Y) _FP_MUL (Q, 4, R, X, Y) ^~~ /home/EB/sebastian_h/archive/gcc-git/libgcc/conf
Re: Changing base compiler requirement for bootstrapping GNAT
> On 19 Jan 2017, at 13:33, Jakub Jelinek wrote: > > On Thu, Jan 19, 2017 at 01:26:32PM +0100, Andreas Schwab wrote: >> On Jan 19 2017, Tristan Gingold wrote: >> >>> Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ? >> >> The newest Ada compiler available for SLE11 is 4.8. > > Various people still use 4.4 or even 4.1 as bootstrap compilers. > While 3 years old requirement is way better than the Rust nonsense (only > support bootstrap with 6 weeks older Rust and not older), it is still not > good enough for GCC IMHO. For the record, we now have a plan to still allow gcc 4.1 as a bootstrap compiler. Tristan.
-fsanitize=thread support on ppc64
Hi! I've noticed today there is tsan_rtl_ppc64.S file since the latest merge from upstream. Does that mean tsan is supposed to work on ppc64? Just powerpc64le-*-linux*, or powerpc64-*-linux* too? If yes, then libsanitizer/configure.tgt should be changed to reflect that change. Jakub
Successful bootstrap and installation of gcc 6.3.0 on x86_64-pc-linux-gnu
Hi, I have successfully bootstrapped and installed a release version of gcc 6.3.0. As I have read at the end of the installation instructions I send you the following information: Output from command 'srcdir/config.guess': x86_64-pc-linux-gnu Output from command 'gcc -v': Using built-in specs. COLLECT_GCC=/home/ciro/Programs/GCC_Binutils/GCC-6.3.0/Install/bin/gcc COLLECT_LTO_WRAPPER=/home/ciro/Programs/GCC_Binutils/GCC-6.3.0/Install/libex ec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-6.3.0/configure --prefix=/home/ciro/Programs/GCC_Binutils/GCC-6.3.0/Install Thread model: posix gcc version 6.3.0 (GCC) Whether you enabled all languages or a subset of them: I did not exclude / include any specific language, but because I did not have a previous version of the Ada compiler, the new Ada Compiler was not built. So the compilers for all the languages were built, except that for Ada. Content of /etc/issue: Debian GNU/Linux 8 \n \l Output from command 'uname --version': uname (GNU coreutils) 8.23 Output from command 'uname -a': Linux FissoDellDebian 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux Output from command 'dpkg -l libc6': Name Version Architecture Description +++-=-=-=-== == ii libc6:amd64 2.19-18+deb8u7amd64 GNU C Library: Shared libraries ii libc6:i386 2.19-18+deb8u7i386 GNU C Library: Shared libraries the host/target specific installation notes includes my host/target and it is not incomplete or out of date. Note: during the bootstrap, after configured, while running 'make', the program halted just before building the Java compiler, because it could not find any "jar" or "zip" executable. I installed Debian Packages "fastjar" and "zip", run "make" again and it worked. Many thanks to you all. Ciro Landolfi
Re: -fsanitize=thread support on ppc64
Hi, On 23/01/17 14:33, Jakub Jelinek wrote: Hi! I've noticed today there is tsan_rtl_ppc64.S file since the latest merge from upstream. Does that mean tsan is supposed to work on ppc64? Just powerpc64le-*-linux*, or powerpc64-*-linux* too? FWIW LLVM has build bots for both ppc64le-linux and ppc64be-linux, see: http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux Thus TSan is supposed to work on ppc64, I guess. -Maxim If yes, then libsanitizer/configure.tgt should be changed to reflect that change. Jakub
Re: GCC libatomic ABI specification draft
Hi, On Fri, 20 Jan 2017, Richard Henderson wrote: > > You can't have a 4-aligned type of size 3. Sizes must be multiples of > > alignment (otherwise arrays don't work). The type of a 3-sized field > > in a packed struct that syntactically might be a 4-aligned type (e.g. > > by using attributes on char-array types) is actually a different type > > having an alignment of 1. It's easier to simply regard all types > > inside packed structs as 1-aligned (which is IMO what we try to do). > > > > That is, the byte after a 4-aligned "3-sized" type is always padding. > > [ I read Bin Fan's original email some months ago, but I don't have it handy > now. Take faulty memory with a grain of salt. ] > > I thought this was about libatomic being presented with an unaligned 3-byte > structure that happens to sit within an aligned 4-byte word, and choosing to > atomically operate on the 4-byte word instead of taking a lock on the side. Ah well, in that case I lost context as well ;) Ciao, Michael.
Re: -fsanitize=thread support on ppc64
TSan support was contributed to LLVM by a student working at one of the US National Labs a while back. I helped him with some of the PPC assembly programming. To my knowledge this is working, but I haven't tested this with GCC. Do you think we want to change the configuration for GCC this late in the release? I can run a quick test with TSan turned on to see where we're at. -- Bill Bill Schmidt, Ph.D. GCC for Linux on Power Linux on Power Toolchain IBM Linux Technology Center wschm...@linux.vnet.ibm.com > On Jan 23, 2017, at 6:53 AM, Maxim Ostapenko wrote: > > Hi, > > On 23/01/17 14:33, Jakub Jelinek wrote: >> Hi! >> >> I've noticed today there is tsan_rtl_ppc64.S file since the latest >> merge from upstream. Does that mean tsan is supposed to work >> on ppc64? Just powerpc64le-*-linux*, or powerpc64-*-linux* too? > > FWIW LLVM has build bots for both ppc64le-linux and ppc64be-linux, see: > http://lab.llvm.org:8011/builders/sanitizer-ppc64le-linux > http://lab.llvm.org:8011/builders/sanitizer-ppc64be-linux > > Thus TSan is supposed to work on ppc64, I guess. > > -Maxim > >> If yes, then libsanitizer/configure.tgt should be changed to reflect that >> change. >> >> Jakub >> >> >
Re: -fsanitize=thread support on ppc64
On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
> TSan support was contributed to LLVM by a student working at one of the US
> National Labs a while back. I helped him with some of the PPC assembly
> programming. To my knowledge this is working, but I haven't tested this with
> GCC. Do you think we want to change the configuration for GCC this late in
> the
> release? I can run a quick test with TSan turned on to see where we're at.
I think it should be enabled if it works, even this late.
I bet we need something like the following patch on top of
the PR79168 patch.
I'll test both patches on both ppc64le and ppc64.
Another question is, it seems upstream has s390{,x}-*-linux* support for
asan/ubsan, does that work? In that case we should add it to configure.tgt
too (similarly to the sparc*-*-linux* entry).
2017-01-23 Jakub Jelinek
* configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
--- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
+++ libsanitizer/configure.tgt 2017-01-23 15:25:21.059399613 +0100
@@ -1,5 +1,5 @@
# -*- shell-script -*-
-# Copyright (C) 2012 Free Software Foundation, Inc.
+# Copyright (C) 2012-2017 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -31,6 +31,11 @@ case "${target}" in
fi
;;
powerpc*-*-linux*)
+ if test x$ac_cv_sizeof_void_p = x8; then
+ TSAN_SUPPORTED=yes
+ LSAN_SUPPORTED=yes
+ TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
+ fi
;;
sparc*-*-linux*)
;;
Jakub
Re: -fsanitize=thread support on ppc64
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
>> TSan support was contributed to LLVM by a student working at one of the US
>> National Labs a while back. I helped him with some of the PPC assembly
>> programming. To my knowledge this is working, but I haven't tested this with
>> GCC. Do you think we want to change the configuration for GCC this late in
>> the
>> release? I can run a quick test with TSan turned on to see where we're at.
>
> I think it should be enabled if it works, even this late.
> I bet we need something like the following patch on top of
> the PR79168 patch.
>
> I'll test both patches on both ppc64le and ppc64.
Sounds good, thanks! Let me know if I can help in any way.
>
> Another question is, it seems upstream has s390{,x}-*-linux* support for
> asan/ubsan, does that work? In that case we should add it to configure.tgt
> too (similarly to the sparc*-*-linux* entry).
CCing Uli for the s390 question.
Bill
>
> 2017-01-23 Jakub Jelinek
>
> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>
> --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
> +++ libsanitizer/configure.tgt2017-01-23 15:25:21.059399613 +0100
> @@ -1,5 +1,5 @@
> # -*- shell-script -*-
> -# Copyright (C) 2012 Free Software Foundation, Inc.
> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
>
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> @@ -31,6 +31,11 @@ case "${target}" in
> fi
> ;;
> powerpc*-*-linux*)
> + if test x$ac_cv_sizeof_void_p = x8; then
> + TSAN_SUPPORTED=yes
> + LSAN_SUPPORTED=yes
> + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
> + fi
> ;;
> sparc*-*-linux*)
> ;;
>
>
> Jakub
>
Re: -fsanitize=thread support on ppc64
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:22:30AM -0600, Bill Schmidt wrote:
>> TSan support was contributed to LLVM by a student working at one of the US
>> National Labs a while back. I helped him with some of the PPC assembly
>> programming. To my knowledge this is working, but I haven't tested this with
>> GCC. Do you think we want to change the configuration for GCC this late in
>> the
>> release? I can run a quick test with TSan turned on to see where we're at.
>
> I think it should be enabled if it works, even this late.
> I bet we need something like the following patch on top of
> the PR79168 patch.
>
> I'll test both patches on both ppc64le and ppc64.
>
> Another question is, it seems upstream has s390{,x}-*-linux* support for
> asan/ubsan, does that work? In that case we should add it to configure.tgt
> too (similarly to the sparc*-*-linux* entry).
>
> 2017-01-23 Jakub Jelinek
>
> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>
> --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
> +++ libsanitizer/configure.tgt2017-01-23 15:25:21.059399613 +0100
> @@ -1,5 +1,5 @@
> # -*- shell-script -*-
> -# Copyright (C) 2012 Free Software Foundation, Inc.
> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
>
> # This program is free software; you can redistribute it and/or modify
> # it under the terms of the GNU General Public License as published by
> @@ -31,6 +31,11 @@ case "${target}" in
> fi
> ;;
> powerpc*-*-linux*)
I think you want a separate entry for powerpc64*-*-linux* -- IIRC, the
existing code will definitely not work for 32-bit due to TLS differences.
Thus be sure we don't enable TSAN for powerpc-*-linux.
Bill
> + if test x$ac_cv_sizeof_void_p = x8; then
> + TSAN_SUPPORTED=yes
> + LSAN_SUPPORTED=yes
> + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
> + fi
> ;;
> sparc*-*-linux*)
> ;;
>
>
> Jakub
>
Re: -fsanitize=thread support on ppc64
On Mon, Jan 23, 2017 at 08:45:16AM -0600, Bill Schmidt wrote:
> > 2017-01-23 Jakub Jelinek
> >
> > * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
> >
> > --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
> > +++ libsanitizer/configure.tgt 2017-01-23 15:25:21.059399613 +0100
> > @@ -1,5 +1,5 @@
> > # -*- shell-script -*-
> > -# Copyright (C) 2012 Free Software Foundation, Inc.
> > +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
> >
> > # This program is free software; you can redistribute it and/or modify
> > # it under the terms of the GNU General Public License as published by
> > @@ -31,6 +31,11 @@ case "${target}" in
> > fi
> > ;;
> > powerpc*-*-linux*)
>
> I think you want a separate entry for powerpc64*-*-linux* -- IIRC, the
> existing code will definitely not work for 32-bit due to TLS differences.
> Thus be sure we don't enable TSAN for powerpc-*-linux.
That is handled by the
> > + if test x$ac_cv_sizeof_void_p = x8; then
test (similarly how for both i?86-*-linux* and x86_64-*-linux* it is enabled
only for LP64 multilib and not others). We want to enable it only for the
64-bit multilib, not 32-bit.
> > + TSAN_SUPPORTED=yes
> > + LSAN_SUPPORTED=yes
> > + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
> > + fi
> > ;;
> > sparc*-*-linux*)
> > ;;
Jakub
Re: -fsanitize=thread support on ppc64
> On Jan 23, 2017, at 8:47 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 23, 2017 at 08:45:16AM -0600, Bill Schmidt wrote:
>>> 2017-01-23 Jakub Jelinek
>>>
>>> * configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.
>>>
>>> --- libsanitizer/configure.tgt.jj 2016-11-09 15:22:50.0 +0100
>>> +++ libsanitizer/configure.tgt 2017-01-23 15:25:21.059399613 +0100
>>> @@ -1,5 +1,5 @@
>>> # -*- shell-script -*-
>>> -# Copyright (C) 2012 Free Software Foundation, Inc.
>>> +# Copyright (C) 2012-2017 Free Software Foundation, Inc.
>>>
>>> # This program is free software; you can redistribute it and/or modify
>>> # it under the terms of the GNU General Public License as published by
>>> @@ -31,6 +31,11 @@ case "${target}" in
>>> fi
>>> ;;
>>> powerpc*-*-linux*)
>>
>> I think you want a separate entry for powerpc64*-*-linux* -- IIRC, the
>> existing code will definitely not work for 32-bit due to TLS differences.
>> Thus be sure we don't enable TSAN for powerpc-*-linux.
>
> That is handled by the
>
>>> + if test x$ac_cv_sizeof_void_p = x8; then
>
> test (similarly how for both i?86-*-linux* and x86_64-*-linux* it is enabled
> only for LP64 multilib and not others). We want to enable it only for the
> 64-bit multilib, not 32-bit.
Ah, quite right. Sorry for the sloppy reading.
Bill
>
>>> + TSAN_SUPPORTED=yes
>>> + LSAN_SUPPORTED=yes
>>> + TSAN_TARGET_DEPENDENT_OBJECTS=tsan_rtl_ppc64.lo
>>> + fi
>>> ;;
>>> sparc*-*-linux*)
>>> ;;
>
> Jakub
>
Re: -fsanitize=thread support on ppc64
Bill Schmidt wrote:
> On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
> >
> > Another question is, it seems upstream has s390{,x}-*-linux* support for
> > asan/ubsan, does that work? In that case we should add it to configure.tgt
> > too (similarly to the sparc*-*-linux* entry).
>
> CCing Uli for the s390 question.
Asan support was added just recently to LLVM for s390x-linux. However,
I'm not sure it will work out-of-the-box on GCC, since we haven't done any
back-end work to enable it. Also, LLVM is 64-bit only, so there probably
would have to be extra work in the libraries to enable 31-bit mode.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops
Hi,
I am trying to use gcc-6.3.0 to cross-compile a kernel for an old mips64
platform, an SGI Onyx2 ("IP27"), however, it looks like a large number of
functions within the compiled code are getting a common instruction emitted at
the top of the function that breaks this particular machine.
Doing a disassembly of the kernel binary, this is what the beginning of several
functions looks like:
a801c400 :
a801c400: ffa0bff0sd zero,-16400(sp)
a801c404: 67bdfff0daddiu sp,sp,-16
a801cea0 :
a801cea0: ffa0bfe0sd zero,-16416(sp)
a801cea4: 67bdffe0daddiu sp,sp,-32
a801c5b0 :
a801c5b0: ffa0bf90sd zero,-16496(sp)
a801c5b4: 3c05a800lui a1,0xa800
a801c5b8: 3c020074lui v0,0x74
a801c5bc: 64a5daddiu a1,a1,0
a801c5c0: 64424840daddiu v0,v0,18496
a801c5c4: 0005283cdsll32 a1,a1,0x0
a801c5c8: 67bdff90daddiu sp,sp,-112
If I compare this output against the disassembly of the same kernel tree built
with gcc-5.4.0, I see this:
a801c400 :
a801c400: 67bdfff0daddiu sp,sp,-16
a801c404: 3c02007blui v0,0x7b
a801cec0 :
a801cec0: 67bdffe0daddiu sp,sp,-32
a801cec4: ffb0sd s0,0(sp)
a801c5a0 :
a801c5a0: 3c05a800lui a1,0xa800
a801c5a4: 3c020075lui v0,0x75
a801c5a8: 64a5daddiu a1,a1,0
a801c5ac: 64423f40daddiu v0,v0,16192
a801c5b0: 0005283cdsll32 a1,a1,0x0
a801c5b4: 67bdff90daddiu sp,sp,-112
I am not sure what this lone store-doubleword instruction is exactly doing, nor
can I locate where in the gcc MIPS code it is being generated from. On the
IP27 platform, it breaks the '_raw_spin_lock_irq' function, which is a
hard-coded block of assembly code in the kernel at
arch/mips/include/asm/spinlock.h, taking the 'else' branch of the if clause:
https://git.linux-mips.org/cgit/ralf/linux.git/tree/arch/mips/include/asm/spinlock.h
This "sd" instruction triggers an attempted NULL pointer dereference attempt
when processing the load-linked instruction at the top of the assembly, which
crashes the kernel early in the boot process (after checking for the 'daddi'
bug).
I have another SGI platform, an Octane ("IP30") that is architecturally-similar
to an IP27, and it is unaffected by the presence of this instruction. IP27 is
a NUMA system, however, while IP30 is not. I am suspecting this contributes to
the issues.
However, I need to know what this "sd" instruction's purpose at the beginning
of each function is, and where in gcc's source it's located so I can see if
this is something fixable within the Linux kernel in the IP27-specific code, or
if it's a code-generation bug.
Thanks!,
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Re: -fsanitize=thread support on ppc64
On Mon, Jan 23, 2017 at 04:10:01PM +0100, Ulrich Weigand wrote:
> Bill Schmidt wrote:
> > On Jan 23, 2017, at 8:32 AM, Jakub Jelinek wrote:
> > >
> > > Another question is, it seems upstream has s390{,x}-*-linux* support for
> > > asan/ubsan, does that work? In that case we should add it to
> > > configure.tgt
> > > too (similarly to the sparc*-*-linux* entry).
> >
> > CCing Uli for the s390 question.
>
> Asan support was added just recently to LLVM for s390x-linux. However,
> I'm not sure it will work out-of-the-box on GCC, since we haven't done any
> back-end work to enable it. Also, LLVM is 64-bit only, so there probably
> would have to be extra work in the libraries to enable 31-bit mode.
It could be enabled for 64-bit s390 only too (by setting
UNSUPPORTED=1
if test x$ac_cv_sizeof_void_p != x8
).
And indeed, it would require at least something like:
/* Implement the TARGET_ASAN_SHADOW_OFFSET hook. */
static unsigned HOST_WIDE_INT
s390_asan_shadow_offset (void)
{
return TARGET_64BIT ? (HOST_WIDE_INT_1 << 52) : HOST_WIDE_INT_C (0x2000);
}
and
#undef TARGET_ASAN_SHADOW_OFFSET
#define TARGET_ASAN_SHADOW_OFFSET s390_asan_shadow_offset
(the constants are just from quick skimming of
libsanitizer/asan/asan_mapping.h).
Jakub
Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops
On 23/01/17 15:26, Joshua Kinard wrote: > I am not sure what this lone store-doubleword instruction is exactly doing, > nor > can I locate where in the gcc MIPS code it is being generated from. It's a stack probe, making sure that there is enough stack space. Its only purpose is to provide a SEGV if there is not enough kernel stack. Look for`-fstack-check' as a GCC argument. Andrew.
Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops
On 01/23/2017 10:34, Andrew Haley wrote: > On 23/01/17 15:26, Joshua Kinard wrote: >> I am not sure what this lone store-doubleword instruction is exactly doing, >> nor >> can I locate where in the gcc MIPS code it is being generated from. > > It's a stack probe, making sure that there is enough stack space. Its > only purpose is to provide a SEGV if there is not enough kernel stack. > > Look for`-fstack-check' as a GCC argument. > > > Andrew. Okay, that explains that. I rebuilt the affected kernel with '-fno-stack-check', and that particular platform boots now (it has other issues, but it at least gets past early init). So now the question is why stack-probing kills this machine on generic MIPS code that its smaller cousin is seemingly unaffected by. I do know that IP27 has a different set of memory initialization routines in the MIPS code, so is it possible that, at the point that _raw_spin_lock_irq is called and the stack-probe happens, that there isn't any stack space available because the IP27-specific memory init hasn't yet completed? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops
On 23/01/17 16:11, Joshua Kinard wrote: > So now the question is why stack-probing kills this machine on generic MIPS > code that its smaller cousin is seemingly unaffected by. I do know that IP27 > has a different set of memory initialization routines in the MIPS code, so is > it possible that, at the point that _raw_spin_lock_irq is called and the > stack-probe happens, that there isn't any stack space available because the > IP27-specific memory init hasn't yet completed? I'm sorry, but that really is a question for the kernel people. Andrew.
Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops
On 01/23/2017 11:24, Andrew Haley wrote: > On 23/01/17 16:11, Joshua Kinard wrote: >> So now the question is why stack-probing kills this machine on generic MIPS >> code that its smaller cousin is seemingly unaffected by. I do know that IP27 >> has a different set of memory initialization routines in the MIPS code, so is >> it possible that, at the point that _raw_spin_lock_irq is called and the >> stack-probe happens, that there isn't any stack space available because the >> IP27-specific memory init hasn't yet completed? > > I'm sorry, but that really is a question for the kernel people. > > Andrew. Roger, I will take that up with them then. Thanks for the pointer! -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: How to configure a bi-arch PowerPC GCC?
Hello again,
On Mon, Jan 23, 2017 at 09:19:04AM +0100, Sebastian Huber wrote:
> >>I am flexible in terms of the ABI choice for the 64-bit PowerPC. I guess
> >>the ABI_ELFv2 is the way to go?
> >It certainly is the most modern ABI. It makes some requirements to what
> >Power ISA features are required, which may or may not be a problem for
> >your platform. If you want to use BE, that should work with ELFv2 fine
> >(and it did in the past at least), but it doesn't get serious testing.
>
> I use now the attached patch and get the following error types (for
> several multilibs):
> /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:374:0:
> /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:72:1: error:
> unable to emulate 'TF'
> typedef float TFtype __attribute__ ((mode (TF)));
> ^~~
>From rs6000.c (rs6000_scalar_mode_supported_p):
else if (TARGET_FLOAT128_TYPE && (mode == KFmode || mode == IFmode))
return true;
else
return default_scalar_mode_supported_p (mode);
and the latter has
if (precision == LONG_DOUBLE_TYPE_SIZE)
return true;
return false;
so you have no 128-bit FP type at all. Maybe your TARGET_IEEEQUAD definition
is wrong, maybe something else... What type *do* you want for float128?
> /home/EB/sebastian_h/archive/gcc-git/libgcc/unwind-dw2-fde.c: In
> function 'search_object':
> /home/EB/sebastian_h/archive/gcc-git/libgcc/unwind-dw2-fde.c:588:25:
> internal compiler error: in emit_move_insn, at expr.c:3698
> v1->array[i1+i2] = v1->array[i1-1];
> ~^
> 0x6c49bb emit_move_insn(rtx_def*, rtx_def*)
> /home/EB/sebastian_h/archive/gcc-git/gcc/expr.c:3697
> 0x6a5c2b force_reg
> /home/EB/sebastian_h/archive/gcc-git/gcc/explow.c:648
> 0xd61994 rs6000_legitimize_address
> /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:8873
rs6000_legitimize_address called force_reg which ICEs in emit_move_insn
because the source is not the same mode as the dest (or an immediate, etc.)
You'll have to debug this a bit more to see what is going on.
> /home/EB/sebastian_h/archive/gcc-git/libgcc/emutls.c:171:13: note:
> include '' or provide a declaration of 'realloc'
> /tmp/ccoZ1J0W.s: Assembler messages:
> /tmp/ccoZ1J0W.s:125: Error: can't resolve `.got' {.got section} -
> `.LCTOC1' {*UND* section}
Your TLS is misconfigured. Or something.
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -2381,7 +2381,7 @@ powerpc-*-eabi*)
> use_gcc_stdint=wrap
> ;;
> powerpc-*-rtems*)
> - tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h
> rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/rtems.h rtems.h"
> + tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h freebsd-spec.h
> newlib-stdint.h rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/rtems.h
> rtems.h"
> extra_options="${extra_options} rs6000/sysv4.opt"
> tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems
> rs6000/t-ppccomm"
> ;;
You might want to break this line into parts. It isn't so easy to see what
you changed now :-)
Have you checked if your generated files (say, those in libgcc) are
actually ELFv2 now, and if they look correct?
Segher
GCC function calling: Parameter passing on stack...
Hi All, I am doing a port of GCC for a small internal processor and I have a question about function parameter passing. I am allocating space for function parameters on the frame (via crtl->outgoing_args_size) and want gcc to use this space via frame pointer manipulation, not stack pointer manipulation. So far, I cannot get gcc to use the frame pointer for the args, it manipulates the stack pointer directly (this is a problem since the stack pointer is not directly accessible). I have the following configurations set: #define ACCUMULATE_OUTGOING_ARGS (1) #define REG_PARM_STACK_SPACE(x) (0) //NOT USED #define INCOMING_REG_PARM_STACK_SPACE #define OUTGOING_REG_PARM_STACK_SPACE(x) (1) #define STACK_PARMS_IN_REG_PARM_AREA (1) but these do not seem to help. The compiler uses the frame pointer correctly for all the local variables, so I know it is aware of it. Any suggestions are appreciated. Steve (Broadcom)
