Re: build broken on ppc linux?!
On Nov 22, 2013, at 10:13 AM, Jakub Jelinek wrote: >> This is exactly the patch referenced in the pointer to the upstream repo. >> Arno, does this fix the build for you? >> >> Ok? > > Yes Committed revision 205285.
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 07:21:07PM +0100, Arnaud Charlet wrote:
> > This is exactly the patch referenced in the pointer to the upstream repo.
> > Arno, does this fix the build for you?
>
> Well now I encounter:
>
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
> function '__sanitizer::uptr
> __sanitizer::internal_filesize(__sanitizer::fd_t)':
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:176:19:
> warning: 'st.stat::st_size' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>return (uptr)st.st_size;
>^
>
> So I guess that's what we call "progress".
>
> I'll keep using --disable-libsanitizer for the time being, this library is
> clearly not quite productized yet IMO.
Here is a patch to fix various warnings, the remaining ones I'm seeing are
mostly that libsanitizer uses incorrectly C90/C++98 ... in macros (the
standard require it to be non-empty), either use the GNU extension
instead, #define INTERCEPTOR(a, b, c...) and ,## c if needed to get rid
of the preceeding comma if empty (though, you compile with -pedantic, so
might get warnings about that too), or rework the macros or have different
ones for the zero argument cases (INTERCEPTOR0).
There are some additional warnings caused by the #ifdef SYSCALL_INTERCEPTION
hacks we have to avoid various issues with problematic kernel headers or
libsanitizer code not having non-i?86/x86_64 in mind.
The sanitizer_syscall_linux_x86_64.inc changes fix real bugs, the rest is
just to get the noise level down.
--- sanitizer_common/sanitizer_linux.cc.jj 2013-11-12 11:31:00.0
+0100
+++ sanitizer_common/sanitizer_linux.cc 2013-11-22 20:15:26.652376137 +0100
@@ -216,7 +216,7 @@ uptr GetTid() {
}
u64 NanoTime() {
- kernel_timeval tv = {};
+ kernel_timeval tv = {0, 0};
internal_syscall(__NR_gettimeofday, (uptr)&tv, 0);
return (u64)tv.tv_sec * 1000*1000*1000 + tv.tv_usec * 1000;
}
--- sanitizer_common/sanitizer_syscall_linux_x86_64.inc.jj 2013-11-12
11:31:00.0 +0100
+++ sanitizer_common/sanitizer_syscall_linux_x86_64.inc 2013-11-22
20:14:32.752657581 +0100
@@ -11,7 +11,7 @@
static uptr internal_syscall(u64 nr) {
u64 retval;
- asm volatile("syscall" : "=a"(retval) : "a"(nr) : "rcx", "r11");
+ asm volatile("syscall" : "=a"(retval) : "a"(nr) : "rcx", "r11", "memory");
return retval;
}
@@ -19,7 +19,7 @@ template
static uptr internal_syscall(u64 nr, T1 arg1) {
u64 retval;
asm volatile("syscall" : "=a"(retval) : "a"(nr), "D"((u64)arg1) :
- "rcx", "r11");
+ "rcx", "r11", "memory");
return retval;
}
@@ -27,7 +27,7 @@ template
static uptr internal_syscall(u64 nr, T1 arg1, T2 arg2) {
u64 retval;
asm volatile("syscall" : "=a"(retval) : "a"(nr), "D"((u64)arg1),
- "S"((u64)arg2) : "rcx", "r11");
+ "S"((u64)arg2) : "rcx", "r11", "memory");
return retval;
}
@@ -35,7 +35,7 @@ template
Re: build broken on ppc linux?!
> This is exactly the patch referenced in the pointer to the upstream repo. > Arno, does this fix the build for you? Well now I encounter: /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function '__sanitizer::uptr __sanitizer::internal_filesize(__sanitizer::fd_t)': /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:176:19: warning: 'st.stat::st_size' may be used uninitialized in this function [-Wmaybe-uninitialized] return (uptr)st.st_size; ^ So I guess that's what we call "progress". I'll keep using --disable-libsanitizer for the time being, this library is clearly not quite productized yet IMO. Arno
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 10:11:18AM -0800, Mike Stump wrote: > On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany > wrote: > > These CFI directives were completely removed in upstream at > > http://llvm.org/viewvc/llvm-project?rev=192196&view=rev > > Strangely, this did not get into the last merge... > > > > Anyway, these cfi_* will (should, at least) disappear with the next > > merge which I hope to do in ~ 1 week. > > (Or anyone is welcome to delete these now as a separate commit, but > > please make sure the code matches the one in upstream) > > This is exactly the patch referenced in the pointer to the upstream repo. > Arno, does this fix the build for you? > > Ok? Yes (though, I really wonder why it needs to be removed rather than only conditionally added based on preprocessor macros, but that is a question for upstream). Jakub
Re: build broken on ppc linux?!
On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany wrote: > These CFI directives were completely removed in upstream at > http://llvm.org/viewvc/llvm-project?rev=192196&view=rev > Strangely, this did not get into the last merge... > > Anyway, these cfi_* will (should, at least) disappear with the next > merge which I hope to do in ~ 1 week. > (Or anyone is welcome to delete these now as a separate commit, but > please make sure the code matches the one in upstream) This is exactly the patch referenced in the pointer to the upstream repo. Arno, does this fix the build for you? Ok? Index: libsanitizer/sanitizer_common/sanitizer_linux.cc === --- libsanitizer/sanitizer_common/sanitizer_linux.cc(revision 205278) +++ libsanitizer/sanitizer_common/sanitizer_linux.cc(working copy) @@ -785,7 +785,6 @@ uptr internal_clone(int (*fn)(void *), v *%r8 = new_tls, *%r10 = child_tidptr) */ - ".cfi_endproc\n" "syscall\n" /* if (%rax != 0) @@ -795,8 +794,9 @@ uptr internal_clone(int (*fn)(void *), v "jnz1f\n" /* In the child. Terminate unwind chain. */ - ".cfi_startproc\n" - ".cfi_undefined %%rip;\n" + // XXX: We should also terminate the CFI unwind chain + // here. Unfortunately clang 3.2 doesn't support the + // necessary CFI directives, so we skip that part. "xorq %%rbp,%%rbp\n" /* Call "fn(arg)". */
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 7:00 PM, FX wrote: >> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: >> Assembler messages: >> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: >> Error: .cfi_endproc without corresponding .cfi_startproc >> :21485: Error: open CFI at the end of file; missing .cfi_endproc directive >> make[4]: *** [sanitizer_linux.lo] Error 1 > > I’ve posted this to the list before, and turns out you need “recent” linux > kernel and “recent” binutils to bootstrap GCC these days. But to keep the > fun, “recent” is neither document, nor tested at configure time, so you end > up with useless error messages. > > I’ve filed bug reports about it > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59067 and > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068), which have been dutifuly > ignored. My opinion is that unless the level of support of libsanitizer is > increased, it should not be built by default (or build it only if it’s > supported). Causing such bootstrap issues would not be tolerated in other > parts of the compiler. I am all for disabling libsanitizer if something in the tool chain is old (binutils, kernel, compiler, etc). > > FX
Re: build broken on ppc linux?!
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: > Assembler messages: > /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: > Error: .cfi_endproc without corresponding .cfi_startproc > :21485: Error: open CFI at the end of file; missing .cfi_endproc directive > make[4]: *** [sanitizer_linux.lo] Error 1 I’ve posted this to the list before, and turns out you need “recent” linux kernel and “recent” binutils to bootstrap GCC these days. But to keep the fun, “recent” is neither document, nor tested at configure time, so you end up with useless error messages. I’ve filed bug reports about it (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59067 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59068), which have been dutifuly ignored. My opinion is that unless the level of support of libsanitizer is increased, it should not be built by default (or build it only if it’s supported). Causing such bootstrap issues would not be tolerated in other parts of the compiler. FX
Re: build broken on ppc linux?!
On Fri, 2013-11-22 at 12:30 +0100, Richard Biener wrote: > On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely > wrote: > > Yes, it only seems to be a problem with SUSE kernels: > > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html > > As my bugreport is being ignored it would help if one ouf our > partners (hint! hint!) would raise this issue via the appropriate > channel ;) Ok, I'll open a bug on our side and we'll see if that helps move things along. Peter
Re: build broken on ppc linux?!
Hi, On Fri, Nov 22, 2013 at 04:36:47PM +0400, Konstantin Serebryany wrote: > On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote: > > On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote: > >> > As my bugreport is being ignored it would help if one ouf our > >> > >> Sorry. Which one? > > > > I believe richi meant > > https://bugzilla.novell.com/show_bug.cgi?id=849180 > > I don't have access there. Sorry, although I thought checked I the bug was public, apparently I did it wrong and it is not. Anyway, it is bug against SLES 11 which does not have the kernel patch to make vt.h C++ compilable. Martin
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 1:36 PM, Konstantin Serebryany wrote: > On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote: >> On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote: >>> > As my bugreport is being ignored it would help if one ouf our >>> >>> Sorry. Which one? >> >> I believe richi meant >> https://bugzilla.novell.com/show_bug.cgi?id=849180 > > I don't have access there. The hint was directed at the IBM people. Richard.
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote: > On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote: >> > As my bugreport is being ignored it would help if one ouf our >> >> Sorry. Which one? > > I believe richi meant > https://bugzilla.novell.com/show_bug.cgi?id=849180 I don't have access there.
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote: > > As my bugreport is being ignored it would help if one ouf our > > Sorry. Which one? I believe richi meant https://bugzilla.novell.com/show_bug.cgi?id=849180 Martin > > > partners (hint! hint!) would raise this issue via the appropriate > > channel ;) :-)
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 4:31 PM, Konstantin Serebryany wrote: > On Fri, Nov 22, 2013 at 3:56 PM, Jakub Jelinek wrote: >> On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote: >>> > >>> Looks like another issue for the libsanitizer maintainers. >>> > >> >>> > >> I've been doing bootstraps, but didn't see this because the >>> > >> kernel header linux/vt.h use on the RHEL6 system I was doing >>> > >> builds on has that field renamed. Looking at our SLES11 >>> > >> devel system I do see the problematic header file. >>> > > >>> > > Yes, it only seems to be a problem with SUSE kernels: >>> > > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html >>> > >>> > As my bugreport is being ignored it would help if one ouf our >>> > partners (hint! hint!) would raise this issue via the appropriate >>> > channel ;) >>> >>> BTW I do not know if this is related, but my build of GCC is stuck >>> currently with this error message: >>> >>> << >>> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: >>> Assembler messages: >>> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: >>> Error: .cfi_endproc without corresponding .cfi_startproc >>> :21485: Error: open CFI at the end of file; missing .cfi_endproc directive >>> make[4]: *** [sanitizer_linux.lo] Error 1 >>> >> >>> >>> Would appreciate a fix/work around! >> >> I guess something like this could fix this. >> Though, no idea if clang has any similar macro, or if llvm always >> uses .cfi_* directives, or what. Certainly for GCC, if >> __GCC_HAVE_DWARF2_CFI_ASM isn't defined, then GCC doesn't emit them >> (either as doesn't support them, or gcc simply hasn't been configured to use >> them, etc.). In that case GCC emits .eh_frame by hand, and it isn't really >> possible to tweak that. Kostya? >> >> --- libsanitizer/sanitizer_common/sanitizer_linux.cc2013-11-12 >> 11:31:00.154740857 +0100 >> +++ libsanitizer/sanitizer_common/sanitizer_linux.cc2013-11-22 >> 12:50:50.107420695 +0100 >> @@ -785,7 +785,9 @@ uptr internal_clone(int (*fn)(void *), v >> *%r8 = new_tls, >> *%r10 = child_tidptr) >> */ >> +#ifdef __GCC_HAVE_DWARF2_CFI_ASM >> ".cfi_endproc\n" >> +#endif >> "syscall\n" >> >> /* if (%rax != 0) >> @@ -795,8 +797,10 @@ uptr internal_clone(int (*fn)(void *), v >> "jnz1f\n" >> >> /* In the child. Terminate unwind chain. */ >> +#ifdef __GCC_HAVE_DWARF2_CFI_ASM >> ".cfi_startproc\n" >> ".cfi_undefined %%rip;\n" >> +#endif >> "xorq %%rbp,%%rbp\n" >> >> /* Call "fn(arg)". */ > > These CFI directives were completely removed in upstream at > http://llvm.org/viewvc/llvm-project?rev=192196&view=rev > Strangely, this did not get into the last merge... Ah, no surprise. The merge was done from llvm's r191666, which is earlier than 192196 > > Anyway, these cfi_* will (should, at least) disappear with the next > merge which I hope to do in ~ 1 week. > (Or anyone is welcome to delete these now as a separate commit, but > please make sure the code matches the one in upstream) > > --kcc > > >> >> Jakub
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 3:56 PM, Jakub Jelinek wrote: > On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote: >> > >>> Looks like another issue for the libsanitizer maintainers. >> > >> >> > >> I've been doing bootstraps, but didn't see this because the >> > >> kernel header linux/vt.h use on the RHEL6 system I was doing >> > >> builds on has that field renamed. Looking at our SLES11 >> > >> devel system I do see the problematic header file. >> > > >> > > Yes, it only seems to be a problem with SUSE kernels: >> > > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html >> > >> > As my bugreport is being ignored it would help if one ouf our >> > partners (hint! hint!) would raise this issue via the appropriate >> > channel ;) >> >> BTW I do not know if this is related, but my build of GCC is stuck >> currently with this error message: >> >> << >> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: >> Assembler messages: >> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: >> Error: .cfi_endproc without corresponding .cfi_startproc >> :21485: Error: open CFI at the end of file; missing .cfi_endproc directive >> make[4]: *** [sanitizer_linux.lo] Error 1 >> >> >> >> Would appreciate a fix/work around! > > I guess something like this could fix this. > Though, no idea if clang has any similar macro, or if llvm always > uses .cfi_* directives, or what. Certainly for GCC, if > __GCC_HAVE_DWARF2_CFI_ASM isn't defined, then GCC doesn't emit them > (either as doesn't support them, or gcc simply hasn't been configured to use > them, etc.). In that case GCC emits .eh_frame by hand, and it isn't really > possible to tweak that. Kostya? > > --- libsanitizer/sanitizer_common/sanitizer_linux.cc2013-11-12 > 11:31:00.154740857 +0100 > +++ libsanitizer/sanitizer_common/sanitizer_linux.cc2013-11-22 > 12:50:50.107420695 +0100 > @@ -785,7 +785,9 @@ uptr internal_clone(int (*fn)(void *), v > *%r8 = new_tls, > *%r10 = child_tidptr) > */ > +#ifdef __GCC_HAVE_DWARF2_CFI_ASM > ".cfi_endproc\n" > +#endif > "syscall\n" > > /* if (%rax != 0) > @@ -795,8 +797,10 @@ uptr internal_clone(int (*fn)(void *), v > "jnz1f\n" > > /* In the child. Terminate unwind chain. */ > +#ifdef __GCC_HAVE_DWARF2_CFI_ASM > ".cfi_startproc\n" > ".cfi_undefined %%rip;\n" > +#endif > "xorq %%rbp,%%rbp\n" > > /* Call "fn(arg)". */ These CFI directives were completely removed in upstream at http://llvm.org/viewvc/llvm-project?rev=192196&view=rev Strangely, this did not get into the last merge... Anyway, these cfi_* will (should, at least) disappear with the next merge which I hope to do in ~ 1 week. (Or anyone is welcome to delete these now as a separate commit, but please make sure the code matches the one in upstream) --kcc > > Jakub
Re: build broken on ppc linux?!
> As my bugreport is being ignored it would help if one ouf our Sorry. Which one? > partners (hint! hint!) would raise this issue via the appropriate > channel ;) > > Richard.
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote: > > >>> Looks like another issue for the libsanitizer maintainers. > > >> > > >> I've been doing bootstraps, but didn't see this because the > > >> kernel header linux/vt.h use on the RHEL6 system I was doing > > >> builds on has that field renamed. Looking at our SLES11 > > >> devel system I do see the problematic header file. > > > > > > Yes, it only seems to be a problem with SUSE kernels: > > > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html > > > > As my bugreport is being ignored it would help if one ouf our > > partners (hint! hint!) would raise this issue via the appropriate > > channel ;) > > BTW I do not know if this is related, but my build of GCC is stuck > currently with this error message: > > << > /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: > Assembler messages: > /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: > Error: .cfi_endproc without corresponding .cfi_startproc > :21485: Error: open CFI at the end of file; missing .cfi_endproc directive > make[4]: *** [sanitizer_linux.lo] Error 1 > >> > > Would appreciate a fix/work around! I guess something like this could fix this. Though, no idea if clang has any similar macro, or if llvm always uses .cfi_* directives, or what. Certainly for GCC, if __GCC_HAVE_DWARF2_CFI_ASM isn't defined, then GCC doesn't emit them (either as doesn't support them, or gcc simply hasn't been configured to use them, etc.). In that case GCC emits .eh_frame by hand, and it isn't really possible to tweak that. Kostya? --- libsanitizer/sanitizer_common/sanitizer_linux.cc2013-11-12 11:31:00.154740857 +0100 +++ libsanitizer/sanitizer_common/sanitizer_linux.cc2013-11-22 12:50:50.107420695 +0100 @@ -785,7 +785,9 @@ uptr internal_clone(int (*fn)(void *), v *%r8 = new_tls, *%r10 = child_tidptr) */ +#ifdef __GCC_HAVE_DWARF2_CFI_ASM ".cfi_endproc\n" +#endif "syscall\n" /* if (%rax != 0) @@ -795,8 +797,10 @@ uptr internal_clone(int (*fn)(void *), v "jnz1f\n" /* In the child. Terminate unwind chain. */ +#ifdef __GCC_HAVE_DWARF2_CFI_ASM ".cfi_startproc\n" ".cfi_undefined %%rip;\n" +#endif "xorq %%rbp,%%rbp\n" /* Call "fn(arg)". */ Jakub
Re: build broken on ppc linux?!
> > Would appreciate a fix/work around! > > Configure with --disable-libsanitizer. Will do, thanks.
Re: build broken on ppc linux?!
> Would appreciate a fix/work around! Configure with --disable-libsanitizer. -- Eric Botcazou
Re: build broken on ppc linux?!
> >>> Looks like another issue for the libsanitizer maintainers. > >> > >> I've been doing bootstraps, but didn't see this because the > >> kernel header linux/vt.h use on the RHEL6 system I was doing > >> builds on has that field renamed. Looking at our SLES11 > >> devel system I do see the problematic header file. > > > > Yes, it only seems to be a problem with SUSE kernels: > > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html > > As my bugreport is being ignored it would help if one ouf our > partners (hint! hint!) would raise this issue via the appropriate > channel ;) BTW I do not know if this is related, but my build of GCC is stuck currently with this error message: << /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: Assembler messages: /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821: Error: .cfi_endproc without corresponding .cfi_startproc :21485: Error: open CFI at the end of file; missing .cfi_endproc directive make[4]: *** [sanitizer_linux.lo] Error 1 >> Would appreciate a fix/work around! Arno
Re: build broken on ppc linux?!
On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely wrote: > On 21 November 2013 21:17, Peter Bergner wrote: >> On Thu, 2013-11-21 at 16:03 -0500, David Edelsohn wrote: >>> Looks like another issue for the libsanitizer maintainers. >> >> I've been doing bootstraps, but didn't see this because the >> kernel header linux/vt.h use on the RHEL6 system I was doing >> builds on has that field renamed. Looking at our SLES11 >> devel system I do see the problematic header file. > > Yes, it only seems to be a problem with SUSE kernels: > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html As my bugreport is being ignored it would help if one ouf our partners (hint! hint!) would raise this issue via the appropriate channel ;) Richard.
