Re: [BUILDROBOT] s390.md:10630:9: error: this statement may fall through [-Werror=implicit-fallthrough=]
> function ?const char* output_1786(rtx_def**, rtx_insn*)?: > /home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10630: > 9: error: this statement may fall through [-Werror=implicit-fallthrough=] > if (larl_operand (operands[0], Pmode)) > ^~ > /home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10632: > 7: note: here >default: >^~~ > cc1plus: all warnings being treated as errors > Makefile:1097: recipe for target 'insn-output.o' failed Fixed. Thanks for reporting! -Andreas-
Reduced source set
Hi, for local version of different gcc version (c/c++ - only) we want to minimize the size of the sources in our local git. What can be removed without problems? Best, -Bernhard
LSDA unwind information is off by one (in __gcc_personality_v0)
We have a fun little glibc bug which causes pthread_cond_wait to write
out of bounds on i386:
https://sourceware.org/bugzilla/show_bug.cgi?id=20719
Root cause is this in libgcc/unwind-c.c:
130 int ip_before_insn = 0;
…
158 /* Parse the LSDA header. */
159 p = parse_lsda_header (context, language_specific_data, &info);
160 #ifdef HAVE_GETIPINFO
161 ip = _Unwind_GetIPInfo (context, &ip_before_insn);
162 #else
163 ip = _Unwind_GetIP (context);
164 #endif
165 if (! ip_before_insn)
166 --ip;
167 landing_pad = 0;
The PC decrement cannot be possibly meaningful on CISC architectures
with variable instruction lengths. I suspect it's an unintentional
leftover from the ia64 port.
I wonder how GCC itself copes with the decrement in
__gcc_personality_v0. This probably matters to Ada the most because it
supports asynchronous exceptions by default.
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with System.Machine_Code; use System.Machine_Code;
procedure Proc is
begin
Asm ("# BEFORE", Volatile => True);
declare
B : Unbounded_String;
begin
Asm ("# WITHIN", Volatile => True);
end;
Asm ("# AFTER", Volatile => True);
end Proc;
Looking at the assembly, there does not seem to be any adjustment for
the off-by-one, but the asynchronous exception handler can be safely
executed multiple times (it has an internal guard flag), so maybe this
never matters. This off-by-one only matters for the exit from exception
handling regions because at the entry, we always get a PC value which is
at least one greater than the initial label because on i386 and x86_64,
the PC coming in from the kernel points after the last executed instruction.
I guess my question is if this is all working as designed.
If the decrement is ever removed from the libgcc unwinder, we should add
a compensating NOP in the glibc code. Otherwise, we can just adjust the
unwind tables.
Florian
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On Okt 20 2016, Florian Weimer wrote: > We have a fun little glibc bug which causes pthread_cond_wait to write out > of bounds on i386: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20719 > > Root cause is this in libgcc/unwind-c.c: > > 130 int ip_before_insn = 0; > … > 158 /* Parse the LSDA header. */ > 159 p = parse_lsda_header (context, language_specific_data, &info); > 160 #ifdef HAVE_GETIPINFO > 161 ip = _Unwind_GetIPInfo (context, &ip_before_insn); > 162 #else > 163 ip = _Unwind_GetIP (context); > 164 #endif > 165 if (! ip_before_insn) > 166 --ip; > 167 landing_pad = 0; > > The PC decrement cannot be possibly meaningful on CISC architectures with > variable instruction lengths. I suspect it's an unintentional leftover > from the ia64 port. It is valid for all architectures, because the return IP usually points _after_ the call instruction, which may already be inside the next unwind region. The situation is different for signal frame. See libgcc/unwind-dw2.c:_Unwind_GetIPInfo for the correct way to handle it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On 10/20/2016 10:28 AM, Florian Weimer wrote:
We have a fun little glibc bug which causes pthread_cond_wait to write
out of bounds on i386:
https://sourceware.org/bugzilla/show_bug.cgi?id=20719
Root cause is this in libgcc/unwind-c.c:
130 int ip_before_insn = 0;
…
158 /* Parse the LSDA header. */
159 p = parse_lsda_header (context, language_specific_data, &info);
160 #ifdef HAVE_GETIPINFO
161 ip = _Unwind_GetIPInfo (context, &ip_before_insn);
162 #else
163 ip = _Unwind_GetIP (context);
164 #endif
165 if (! ip_before_insn)
166 --ip;
167 landing_pad = 0;
The PC decrement cannot be possibly meaningful on CISC architectures
with variable instruction lengths. I suspect it's an unintentional
leftover from the ia64 port.
I wonder how GCC itself copes with the decrement in
__gcc_personality_v0. This probably matters to Ada the most because it
supports asynchronous exceptions by default.
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with System.Machine_Code; use System.Machine_Code;
procedure Proc is
begin
Asm ("# BEFORE", Volatile => True);
declare
B : Unbounded_String;
begin
Asm ("# WITHIN", Volatile => True);
end;
Asm ("# AFTER", Volatile => True);
end Proc;
Looking at the assembly, there does not seem to be any adjustment for
the off-by-one, but the asynchronous exception handler can be safely
executed multiple times (it has an internal guard flag), so maybe this
never matters. This off-by-one only matters for the exit from exception
handling regions because at the entry, we always get a PC value which is
at least one greater than the initial label because on i386 and x86_64,
the PC coming in from the kernel points after the last executed
instruction.
I guess my question is if this is all working as designed.
If the decrement is ever removed from the libgcc unwinder, we should add
a compensating NOP in the glibc code. Otherwise, we can just adjust the
unwind tables.
So the issue is the PC is expected to be pointing to the start of the
next instruction after whatever threw the exception.
Thus the -1 to get back into the right region.
We've had to do similar hackery in gdb, memstomp and probably elsewhere
to deal with this slightly undesirable situation.
Obviously if the PC value is actually pointing at the proper
instruction, then the decrement is highly undesirable as it could put
the adjusted PC into a different exception region.
Jeff
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On 10/20/2016 07:17 PM, Andreas Schwab wrote: On Okt 20 2016, Florian Weimer wrote: We have a fun little glibc bug which causes pthread_cond_wait to write out of bounds on i386: https://sourceware.org/bugzilla/show_bug.cgi?id=20719 Root cause is this in libgcc/unwind-c.c: 130 int ip_before_insn = 0; … 158 /* Parse the LSDA header. */ 159 p = parse_lsda_header (context, language_specific_data, &info); 160 #ifdef HAVE_GETIPINFO 161 ip = _Unwind_GetIPInfo (context, &ip_before_insn); 162 #else 163 ip = _Unwind_GetIP (context); 164 #endif 165 if (! ip_before_insn) 166 --ip; 167 landing_pad = 0; The PC decrement cannot be possibly meaningful on CISC architectures with variable instruction lengths. I suspect it's an unintentional leftover from the ia64 port. It is valid for all architectures, because the return IP usually points _after_ the call instruction, which may already be inside the next unwind region. I think it's less a property of the PC location, and more a property of how the call instruction is unwound, i.e. if you get this address by direct stack unwinding, you want to be the callee nested in the caller's exception handling region. Subtracting 1 is an extremely hackish way to achieve that and likely is not portable at all. The situation is different for signal frame. Indeed. But there, you get the PC of the instruction to execute next (maybe with the exception of some faulting instructions). Except that you need different semantics because the signal handler is not supposed to be nested in the exception handler region. See libgcc/unwind-dw2.c:_Unwind_GetIPInfo for the correct way to handle it. We don't call _Unwind_GetIPInfo from __gcc_personality_v0 because HAVE_GETIPINFO is not defined. This happens only when using the system unwinder on ia64, if I'm not mistaken. Disassembly shows that the code is not compiled in and not part of libgcc_s.so.1, although _Unwind_GetIPInfo itself has been defined. Thanks, Florian
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On 10/20/2016 08:37 PM, Jeff Law wrote: Obviously if the PC value is actually pointing at the proper instruction, then the decrement is highly undesirable as it could put the adjusted PC into a different exception region. Yes, that's what's happening with the glibc bug. The question is how to fix this. We can adjust the unwind tables in glibc to the current behavior easily enough. The instructions involved are longer than one byte, so we should be able to compensate for a potential future libgcc which implements non-call unwinding correctly. The other question is whether we really want to fix libgcc in this way, after all these years, and change the interpretation of unwind tables basically over night. We could perhaps add another personality routine to get a cleaner transition. And the final question is we can trust current GCC to emit correct unwind tables for code which involves non-call exceptions (such as cancellation handlers in glibc, when we don't write them manually in assembler). Thanks, Florian
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On 10/20/2016 11:51 AM, Florian Weimer wrote: exception handling region. Subtracting 1 is an extremely hackish way to achieve that and likely is not portable at all. Gdb has been doing this for over 25 years for every architecture. When you use the backtrace command, it gets a return address, subtracts one, and then does a file name/line number lookup. This is because the file name and source line number of the call instruction may not be the same as the instruction after the call. This does of course assume that you have a return address, and are doing some kind of range based lookup on addresses, so you don't need an exact instruction address to get a hit. Exception regions work the same way. I think that there is some sort of configure related problem here, as HAVE_GETIPINFO is set when I build on an Ubuntu x86_64-linux system. Looking at the configure test, which is in config/unwind_ipinfo.m4... if you don't use --with-system-libunwind, then HAVE_GETIPINFO defaults to on. If you do use --with-system-libunwind, then HAVE_GETIPINFO defaults to off, which will break handling for signal frames. I'm not sure if anyone is using --with-system-libunwind, so I'm not sure if this needs a gcc bug report. But I also see that while HAVE_GETIPINFO appears to be set by configure, it is apparently not being used when building unwind-c.o. I see that HAVE_GETIPINFO is set in the libgcc/auto-target.h file, but this file is not included by unwind-c.c. I only see includes of this in libgcc/config/i386/cpuinfo.c and libgcc/config/sol2/gmon.c. I don't know offhand how auto-target.h is supposed to work, but it appears that it needs to be included in the unwind files built as part of libgcc. This is maybe a bug accidentally caused when libgcc was moved out of the gcc dir and into its own top level dir. I think this warrants a gcc bug report. Jim
Re: Reduced source set
On 20 October 2016 at 16:13, Bernhard Schommer wrote: > Hi, > > for local version of different gcc version (c/c++ - only) we want to > minimize the size of the sources in our local git. What can be removed > without problems? What kind of problems? Do you care about optional things like the sanitizers? OpenMP? Transactional memory? If you want the absolute minimum I think you can remove all the lib*/ sub-dirs except libcpp, libgcc and libstdc++. I imagine you could remove gcc/ada, gcc/fortran, gcc/go, gcc/objc, gcc/jit, gcc/objc, gcc/objcp If you only care about some targets you could remove various config/* sub-dirs. If you don't care about testing maybe you could remove the testsuites files.
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
> We don't call _Unwind_GetIPInfo from __gcc_personality_v0 because > HAVE_GETIPINFO is not defined. This happens only when using the system > unwinder on ia64, if I'm not mistaken. > > Disassembly shows that the code is not compiled in and not part of > libgcc_s.so.1, although _Unwind_GetIPInfo itself has been defined. Then that's the bug, the C++ and Ada personality rountines call it. -- Eric Botcazou
gcc-6-20161020 is now available
Snapshot gcc-6-20161020 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161020/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 241386 You'll find: gcc-6-20161020.tar.bz2 Complete GCC MD5=98f94210cbdc38f3e1e630b88cf17d7b SHA1=96e31c8f5b9a982efcfe5f8e348bc5b7e625ba01 Diffs from 6-20161013 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
