[valgrind] [Bug 458378] New: Suppress errors from setproctitle() on FreeBSD
https://bugs.kde.org/show_bug.cgi?id=458378 Bug ID: 458378 Summary: Suppress errors from setproctitle() on FreeBSD Product: valgrind Version: 3.19.0 Platform: Other OS: FreeBSD Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: dilyan.palau...@aegee.org Target Milestone: --- On FreeBSD 13.1 calls to setproctitle() shall not trigger invalid read/write. That is, errors from setproctitle() in libc.so.7 shall be suppressed in freebsd.supp. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266036 and https://github.com/cyrusimap/cyrus-imapd/issues/4216 . -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 400119] New: Library search path in Valgrind/ldd
https://bugs.kde.org/show_bug.cgi?id=400119 Bug ID: 400119 Summary: Library search path in Valgrind/ldd Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: helgrind Assignee: jsew...@acm.org Reporter: dilyan.palau...@aegee.org Target Milestone: --- When I call "evolution" it executes normally. When I call "valgrind --tool=helgrind evolution" it print things, then comes “ ==28985== This conflicts with a previous write of size 8 by thread #1 ==28985== Locks held: 1, at address 0x24D28670 ==28985==at 0xA5BCFD4: g_signal_newv (gsignal.c:1706) ==28985==by 0xA5BD7EC: g_signal_new_valist (gsignal.c:1902) ==28985==by 0xA5BD8C8: g_signal_new (gsignal.c:1437) ==28985==by 0xF950552: clutter_device_manager_class_intern_init (clutter-device-manager.c:178) ==28985==by 0xA5C7EC8: g_type_class_ref (gtype.c:2232) ==28985==by 0xA5C8204: g_type_class_ref (gtype.c:2939) ==28985==by 0xA5ADD97: g_object_new_valist (gobject.c:2080) ==28985==by 0xA5ADF5B: g_object_new (gobject.c:1648) ==28985== Address 0xa7ea610 is 0 bytes inside data symbol "g_signal_nodes" ==28985== Failed to initialize gtk+: Unable to initialize the Clutter backend: no available drivers found. ==28985== ==28985== For counts of detected and suppressed errors, rerun with: -v” and that is the end. Why under helgrind is printed “Failed to initialize gtk+: Unable to initialize the Clutter backend: no available drivers found.” but under normal start not? Can it be, that valgrind uses different algorithms to find the shared libraris, than the OS? I might have correct and wrong libraries and the OS happens to load the correct ones. I use the latest valgrind -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 399457] Registering at https://identity.kde.org/ does not handle non ASCII names of people
https://bugs.kde.org/show_bug.cgi?id=399457 --- Comment #3 from Дилян Палаузов --- dilian.palauzov but this is not the point. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395682] Reading debug info
https://bugs.kde.org/show_bug.cgi?id=395682 --- Comment #1 from Дилян Палаузов --- It turns out that when linking with ld.bfd 2.30 or gold 2.31.51.20180630) 1.16 valgrind can read the debug information, but not when ld.bfd 2.31.51.20180630 is used. I described at https://sourceware.org/bugzilla/show_bug.cgi?id=23357 the whole case, and uploaded there the produced binaries. Please read it, I don't want to repeat here the text from there in order keep the total text for the case shorter. While I filled a PR for ld.bfd, I don't state whether the problem is in ld.bfd or in valgrind. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395682] Reading debug info
https://bugs.kde.org/show_bug.cgi?id=395682 --- Comment #2 from Дилян Палаузов --- For the time being programs can either be linked explicitly with gold: gcc -fuse-ld=gold or switch off the implicitly enabled separate-code on Linux/x86: gcc -fuse-ld=bfd -Wl,-z,noseparate-code or change the default linker by replacing '/usr/local/x86_64-pc-linux-gnu/bin/ld' (the path can be different on your system), which is a copy of /usr/local/x86_64-pc-linux-gnu/bin/ld.bfd, with /usr/local/x86_64-pc-linux-gnu/bin/ld.gold . -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396476] Reading debug info of binaries with zero-size PT_LOAD segment
https://bugs.kde.org/show_bug.cgi?id=396476 Дилян Палаузов changed: What|Removed |Added CC||dilyan.palau...@aegee.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 --- Comment #14 from Дилян Палаузов --- Autoconf users willing to compile everything with LTO just by calling ./configure put in /usr/local/etc/config.site: CFLAGS="-O3 -fno-fat-lto-objects -flto" CXXFLAGS="-O3 -fno-fat-lto-objects -flto" LDFLAGS="-Wl,-O1,-s -flto=4" And then any ./configure implies LTO. Just as other programs relying on autoconf doing the right thing do not offer --enable-lto option in ./configure --help, can be compiled with LTO, valgrind./configure --help shall not print --enable-lto. Programmer printing on --help "--enable-lto" don't understand autoconf. This applies also for artificially added -g or -O2 from configure.ac or contained in Makefile* ar, nm and ld from binutils can work with LTO, if they are compiled with plugin support binutils-gdb.git/configure --enable-plugins). When gcc calls ld, it passes the plugin path after -plugin, see. https://sourceware.org/binutils/docs/ld/Options.html#Options (-plugin with one dash). Please note, that gcc's "make install" will not install the LTO plugins on the place, where nm will look from it, if it thinks that plugins are needed. See https://sourceware.org/binutils/docs/binutils/nm.html -> --plugins . If `nm --plugin`, `ar --plugin`, `ranlib --plugin` or `ld -plugin` (with one dash) print 'Unknown option', then they are not compiled correctly. The right output of the above commands is "missing argument". The approach for using LTO is to compile ar/ld with plugin support, rather than using gcc-ld/gcc-ar. When CFLAGS from config.site contains -flto, then valgrind can assume that ar/nm/ld are compiled with plugin support. LTO is more than -flto, there is also -fno-fat-lto-objects, and Clang has its own LTO-world. All that said, what is needed for LTO support is stripping the LTO flags when building coregrind/m_libcsetjmp.c, coregrind/m_main.c and VEX/auxprogs/genoffsets.c, assuming that the system is configured correctly with the LTO plugins and ar/ld supporting plugins, or find out why LTO makes problems with those files. Compling everything with LTO produces: In file included from m_syswrap/syswrap-main.c:46: m_syswrap/syswrap-main.c: In function ‘putSyscallStatusIntoGuestState’: m_syswrap/syswrap-main.c:1135:14: error: ‘OFFSET_amd64_RAX’ undeclared (first use in this function) OFFSET_amd64_RAX, sizeof(UWord) ); ^~~~ The diff between VEX/auxprogs/genoffsets.s generated from VEX/auxprogs/genoffsets.c with and without LTO is: --- VEX/auxprogs/genoffsets.s-2 2018-03-12 14:33:05.473476269 +0100 +++ ../valgrind/VEX/auxprogs/genoffsets.s-2 2018-03-12 14:33:14.025483351 +0100 @@ -1,1023 +1,26 @@ .file "genoffsets.c" - .text -.Ltext0: - .globl foo - .type foo, @function -foo: -.LFB17: - .file 1 "./auxprogs/genoffsets.c" - .loc 1 84 1 view -0 - .cfi_startproc - .loc 1 86 4 view .LVU1 -#APP -# 86 "./auxprogs/genoffsets.c" 1 - -#define OFFSET_x86_EAX xyzzy$8 - -# 0 "" 2 - .loc 1 87 4 view .LVU2 -# 87 "./auxprogs/genoffsets.c" 1 - -#define OFFSET_x86_EBX xyzzy$20 - -# 0 "" 2 (- and other OFFSET_ symbols removed) To generate VEX/pub/libvex_guest_offsets.h this "gcc -O -S -o auxprogs/genoffsets.s ./auxprogs/genoffsets.c" is called, and OFFSET_amd64_RAX is in the output if -flto was not passed on this line. This change resolves the mentioned problem with OFFSET_amd64_RAX: diff --git a/Makefile.vex.am b/Makefile.vex.am index 4ad5ffa..f36708c 100644 --- a/Makefile.vex.am +++ b/Makefile.vex.am @@ -63,9 +63,9 @@ BUILT_SOURCES = pub/libvex_guest_offsets.h CLEANFILES= pub/libvex_guest_offsets.h if COMPILER_IS_CLANG -CFLAGS_FOR_GENOFFSETS = $(CFLAGS) -no-integrated-as +CFLAGS_FOR_GENOFFSETS = -no-integrated-as else -CFLAGS_FOR_GENOFFSETS = $(CFLAGS) +CFLAGS_FOR_GENOFFSETS = endif # This is very uggerly. Need to sed out both "xyzzyN" and Now I get: make[3]: Entering directory '/git/valgrind/memcheck' GEN memcheck-amd64-linux m_translate.c: In function ‘vgPlain_translate’: m_translate.c:1527:39: warning: ‘isWrap’ may be used uninitialized in this function [-Wmaybe-uninitialized] m_translate.c:1518:12: note: ‘isWrap’ was declared here m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_signals.c:2024: error: undefined reference to 'VG_MINIMAL_LONGJMP' m_gdbserver/server.c:1175: error: undefined reference to 'VG_MINIMAL_SETJMP' m_gdbserver/server.c:1193: error: undefined reference to 'VG_MINIMAL_SETJMP' m_debuginfo/readdwarf3.c:5231: error: undefined reference to 'VG_MINIMA
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 --- Comment #16 from Дилян Палаузов --- People either want to compile everything with LTO, or nothing with LTO, or they don't know about LTO. Modifying /usr/local/etc/config.site is not the only way, calling CFLAGS="-flto" ./configure also works (if CFLAGS is not set in config.site) and is not "export"ed, as those take precedence. Doing ./configure && make CFLAGS='-flto' does work, too (https://www.gnu.org/software/make/manual/html_node/Overriding.html) So people willing LTO either know the aforementioned ways to compile with LTO, or they do not insist of having LTO. In fact valgrind and php are the only software I am aware of that doesn't work with LTO, php ignoring LDFLAGS from config.site and postgresql ignoring CFLAGS from config.site, and all the rest is working with both the autoconf principles and with LTO. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 --- Comment #17 from Дилян Палаузов --- Having a global /usr/local/etc/config.site file is not necessary. It is possible to put the file somewhere else and set in env CONFIG_SITE for the current session where the file is that shall be considered. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 --- Comment #19 from Дилян Палаузов --- A waring like "a plugin is needed to handle lto objects" suggests that nm/ar do not find the LTO plugin. For an object file compiled with LTO (and -fno-fat-lto-objects), `nm x.o` will print the symbols there, after it recognizes, that a plugin is needed. If the plugin is not findable by nm, it prints nm: libcoregrind_amd64_linux_a-m_poolalloc.o: plugin needed to handle lto object For the plugin support I have: ls /usr/local/lib/bfd-plugins/ -l total 4 lrwxrwxrwx 1 root staff 65 Mar 14 10:55 liblto_plugin.so -> /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/liblto_plugin.so This location is used by ar, ranlib and nm, but not by ld. I asked at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84861 how to tweak coregrind/m_libcsetjmp.c so that -flto does not delete VG_MINIMAL_LONGJMP and VG_MINIMAL_SETJMP. I guess you have uploaded PRs with the ar crashes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252
--- Comment #20 from Дилян Палаузов ---
With the change below m_libcsetjmp.c links on amd64 correctly with LTO. Is the
change equivalent (apart from cheating gcc restoring rax in in
VG_MINIMAL_LONGJMP)? Is volatile after __asm__ necessary?
diff --git a/coregrind/m_libcsetjmp.c b/coregrind/m_libcsetjmp.c
index 68c101e..5626748 100644
--- a/coregrind/m_libcsetjmp.c
+++ b/coregrind/m_libcsetjmp.c
@@ -382,25 +382,10 @@ __asm__(
#if defined(VGP_amd64_linux) || defined(VGP_amd64_darwin) || \
defined(VGP_amd64_solaris)
-__asm__(
-".text" "\n"
-"" "\n"
-
-#if defined(VGP_amd64_linux) || defined(VGP_amd64_solaris)
-".global VG_MINIMAL_SETJMP" "\n" // rdi = jmp_buf
-"VG_MINIMAL_SETJMP:" "\n"
-
-#elif defined(VGP_amd64_darwin)
-".globl _VG_MINIMAL_SETJMP" "\n" // rdi = jmp_buf
-"_VG_MINIMAL_SETJMP:" "\n"
+__attribute__((returns_twice))
+UWord VG_MINIMAL_SETJMP(VG_MINIMAL_JMP_BUF(_env)) {
-#else
-# error "Huh?"
-#endif
-
-"movq %rax, 0(%rdi)" "\n"
-"movq %rbx, 8(%rdi)" "\n"
-"movq %rcx, 16(%rdi)" "\n"
+__asm__(
"movq %rdx, 24(%rdi)" "\n"
"movq %rdi, 32(%rdi)" "\n"
"movq %rsi, 40(%rdi)" "\n"
@@ -421,22 +406,13 @@ __asm__(
"movq $0, %rax" "\n"
"ret" "\n"
"" "\n"
+ );
+}
-
-#if defined(VGP_amd64_linux) || defined(VGP_amd64_solaris)
-".global VG_MINIMAL_LONGJMP" "\n"
-"VG_MINIMAL_LONGJMP:" "\n"// rdi = jmp_buf
-
-#elif defined(VGP_amd64_darwin)
-".globl _VG_MINIMAL_LONGJMP" "\n"
-"_VG_MINIMAL_LONGJMP:" "\n"// rdi = jmp_buf
-
-#else
-# error "Huh?"
-#endif
+__attribute__((noreturn))
+void VG_MINIMAL_LONGJMP(VG_MINIMAL_JMP_BUF(_env)) {
+ __asm__(
// skip restoring rax; it's pointless
-"movq 8(%rdi), %rbx""\n"
-"movq16(%rdi), %rcx""\n"
"movq24(%rdi), %rdx""\n"
// defer restoring rdi; we still need it
"movq40(%rdi), %rsi""\n"
@@ -465,12 +441,8 @@ __asm__(
// address space.
"jmp *%rax" "\n"
"" "\n"
-
-#if !defined(VGP_amd64_darwin)
-".previous" "\n"
-#endif
-);
-
+ );
+}
#endif /* VGP_amd64_linux || VGP_amd64_darwin || VGP_amd64_solaris */
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 391853] New: Makefile.all.am:L247 and @SOLARIS_UNDEF_LARGESOURCE@ being empty
https://bugs.kde.org/show_bug.cgi?id=391853 Bug ID: 391853 Summary: Makefile.all.am:L247 and @SOLARIS_UNDEF_LARGESOURCE@ being empty Product: valgrind Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: dilyan.palau...@aegee.org Target Milestone: --- Makefile.all.am contains: 244: AM_FLAG_M3264_X86_SOLARIS = @FLAG_M32@ 245: AM_CFLAGS_X86_SOLARIS = @FLAG_M32@ @PREFERRED_STACK_BOUNDARY_2@ \ 246:$(AM_CFLAGS_BASE) -fomit-frame-pointer \ 247:@SOLARIS_UNDEF_LARGESOURCE@ 248: AM_CFLAGS_PSO_X86_SOLARIS = @FLAG_M32@ $(AM_CFLAGS_BASE) $(AM_CFLAGS_PSO_BASE) On my system this expands to: VEX/Makefile: 669:AM_FLAG_M3264_X86_SOLARIS = -m32 670:AM_CFLAGS_X86_SOLARIS = -m32 -mpreferred-stack-boundary=2 \ 671:$(AM_CFLAGS_BASE) -fomit-frame-pointer \ 672: 673: 674:AM_CFLAGS_PSO_X86_SOLARIS = -m32 $(AM_CFLAGS_BASE) $(AM_CFLAGS_PSO_BASE) Line 672 consists of four tab characters, and emacs says "Suspicious line 672. Save anyway (y or n)." This helps: diff --git a/Makefile.all.am b/Makefile.all.am --- a/Makefile.all.am +++ b/Makefile.all.am @@ -243,8 +243,7 @@ AM_CCASFLAGS_MIPS64_LINUX = @FLAG_M64@ -g AM_FLAG_M3264_X86_SOLARIS = @FLAG_M32@ AM_CFLAGS_X86_SOLARIS = @FLAG_M32@ @PREFERRED_STACK_BOUNDARY_2@ \ - $(AM_CFLAGS_BASE) -fomit-frame-pointer \ - @SOLARIS_UNDEF_LARGESOURCE@ + $(AM_CFLAGS_BASE) -fomit-frame-pointer @SOLARIS_UNDEF_LARGESOURCE@ AM_CFLAGS_PSO_X86_SOLARIS = @FLAG_M32@ $(AM_CFLAGS_BASE) $(AM_CFLAGS_PSO_BASE) AM_CCASFLAGS_X86_SOLARIS= @FLAG_M32@ -g -D_ASM -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252
Дилян Палаузов changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
Ever confirmed|0 |1
--- Comment #22 from Дилян Палаузов ---
I am against using gcc-ar or gcc-ranlib. These are probably not available,
when clang is used, and it can do LTO, too.
Instead of cluttering configure.ac to use gcc-ac/gcc-ranlib, it can either rely
on the fact, that /usr/(local/)?/bfd-plugins contain the LTO plugin, or
alternatively compile something with -flto to an object file, call "nm
the-object-file.o" and if the latter prints "missing plugin", then configure
shall tell the user that she has to put the linker plugin under
{libdir}/bfd-plugins .
This would help the user to adjust her system to be able to compile other
software with LTO, even software whose authors don't know about LTO.
LTO is anyway not ready for the prime time yet. emacs does not lTO-link with
ld.bfd, but with ld.gold and php also doesn't work with lto. So if the build
process just uses ar/ranlib and it fails, then the user shall try without LTO
or debug, debug, debug...
I would like to know why gcc creates gcc-ar instead of puthing the linker plug
in a place, that normal ar would auto-load it, but I do not expect an answer
here on this.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252
--- Comment #23 from Дилян Палаузов ---
I just verified, that LLVM does not install gcc-ar and gcc-ranlib, but llvm-ar
and llvm-ranlib .
So to make LTO work with Clang, on systems where GCC is not installed, either
llvm-ar and llvm-ranlib shall be used, or ar and ranlib shall be used and it
must be assumed that the system is LTO-ready (the plugins are under
{libdir}/bfd-plugins/).
Concerning installing by default the plugins on the compiler's "make install"
on the location where binutils will look for them I filled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934 and
https://bugs.llvm.org/show_bug.cgi?id=36802.
Shall I open for the assembler-review in coregrind/m_libcsetjmp.c a separate
ticket, or can it be kept here?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 392180] New: LTO build simplification: __asm__ in m_libcsetjmp.c
https://bugs.kde.org/show_bug.cgi?id=392180
Bug ID: 392180
Summary: LTO build simplification: __asm__ in m_libcsetjmp.c
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: dilyan.palau...@aegee.org
Target Milestone: ---
gcc puts __asm__ code within a function into a different partition, compared to
__asm__code outside of functions
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84861). This means, that with
Link-Time-Optimization the __asm__ outside of functions, defining a function,
is not callable from other object files.
commit ab773096d "Fix 338252 - building valgrind with -flto (link time
optimisation) fails" compiles for this reason coregrind/m_libcsetjmp.c and
coregrind/m_main.c explicitly without -flto.
The compilation process will be much easier, if m_libcsetjmp.c defines the
functions VG_MINIMAL_LONGJMP and VG_MINIMAL_SETJMP outside of __asm__ as
suggested at the above link. (I guess the code will then also be easier to
read and maintain).
Evaluate the change below, apply something similar to the other targets and for
m_main.c, and remove in coregrind/Makefile.am the with/without -lflto
distinction logic when compiling m_libcsetjmp.c and m_main.c.
Consider also the discussion at https://bugs.kde.org/show_bug.cgi?id=338252 .
diff --git a/coregrind/m_libcsetjmp.c b/coregrind/m_libcsetjmp.c
index 68c101e..5626748 100644
--- a/coregrind/m_libcsetjmp.c
+++ b/coregrind/m_libcsetjmp.c
@@ -382,25 +382,10 @@ __asm__(
#if defined(VGP_amd64_linux) || defined(VGP_amd64_darwin) || \
defined(VGP_amd64_solaris)
-__asm__(
-".text" "\n"
-"" "\n"
-
-#if defined(VGP_amd64_linux) || defined(VGP_amd64_solaris)
-".global VG_MINIMAL_SETJMP" "\n" // rdi = jmp_buf
-"VG_MINIMAL_SETJMP:" "\n"
-
-#elif defined(VGP_amd64_darwin)
-".globl _VG_MINIMAL_SETJMP" "\n" // rdi = jmp_buf
-"_VG_MINIMAL_SETJMP:" "\n"
+__attribute__((returns_twice))
+UWord VG_MINIMAL_SETJMP(VG_MINIMAL_JMP_BUF(_env)) {
-#else
-# error "Huh?"
-#endif
-
-"movq %rax, 0(%rdi)" "\n"
-"movq %rbx, 8(%rdi)" "\n"
-"movq %rcx, 16(%rdi)" "\n"
+__asm__(
"movq %rdx, 24(%rdi)" "\n"
"movq %rdi, 32(%rdi)" "\n"
"movq %rsi, 40(%rdi)" "\n"
@@ -421,22 +406,13 @@ __asm__(
"movq $0, %rax" "\n"
"ret" "\n"
"" "\n"
+ );
+}
-
-#if defined(VGP_amd64_linux) || defined(VGP_amd64_solaris)
-".global VG_MINIMAL_LONGJMP" "\n"
-"VG_MINIMAL_LONGJMP:" "\n"// rdi = jmp_buf
-
-#elif defined(VGP_amd64_darwin)
-".globl _VG_MINIMAL_LONGJMP" "\n"
-"_VG_MINIMAL_LONGJMP:" "\n"// rdi = jmp_buf
-
-#else
-# error "Huh?"
-#endif
+__attribute__((noreturn))
+void VG_MINIMAL_LONGJMP(VG_MINIMAL_JMP_BUF(_env)) {
+ __asm__(
// skip restoring rax; it's pointless
-"movq 8(%rdi), %rbx""\n"
-"movq16(%rdi), %rcx""\n"
"movq24(%rdi), %rdx""\n"
// defer restoring rdi; we still need it
"movq40(%rdi), %rsi""\n"
@@ -465,12 +441,8 @@ __asm__(
// address space.
"jmp *%rax" "\n"
"" "\n"
-
-#if !defined(VGP_amd64_darwin)
-".previous" "\n"
-#endif
-);
-
+ );
+}
#endif /* VGP_amd64_linux || VGP_amd64_darwin || VGP_amd64_solaris */
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 --- Comment #26 from Дилян Палаузов --- With python 3.6, doing "./configure --with-lto --enable-optimizations && make" compiles with -flto, but calls ranlib/ar, not gcc-ranlib or gcc-ar. Why can python-lto live without gcc-ranlib, but valgrind cannot? Also "./configure --with-lto" alone does not imply -flto. > > Concerning installing by default the plugins on the compiler's "make > > install" on the location where binutils will look for them I filled > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934 and > > https://bugs.llvm.org/show_bug.cgi?id=36802. > Which, as I understand, does not work if you have several gcc versions > installed. It works, as the plugin is backwards compatible. You just install the newest gcc-plugin, it then handles the older versions. In particular, if x86_64-pc-linux-gnu-gcc-6.4.1 is installed on a system before x86_64-pc-linux-gnu-gcc-6.4.1 is installed, and a file is then compiled with 6.4.1, strace shows that gcc-ar calls 7.3.1/liblto_plugin.so . Concerning how LTO-libraries shall be built in portable way - by detecting in ./configure whether gcc or clang is used and then switching to gcc-ranlib or llvm-ranlib and why gcc does recomment gcc-nm instead of installing the plugin at the right place I asked at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 and http://lists.llvm.org/pipermail/llvm-dev/2018-March/122018.html . While both llvm and gcc can do LTO, but considering that after being asked neither on clang side is described how to build the LTO plugin (https://bugs.llvm.org/show_bug.cgi?id=32759#c3) nor on gcc side the plugin is installed on the right place (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345), honestly, I don't think that any of the llvm and gcc teams is willing to put efforts to offer LTO for the masses. For switching the __asm__ in coregrind/m_(main,libcsetjmp).c I opened https://bugs.kde.org/show_bug.cgi?id=392180 . > * allow to configure valgrind using CFLAGS (a.o. to support LTO) How shall this work? I can imagine at first place substituting -S with -E in Makefile.vex.am-92- $(CC) $(CFLAGS_FOR_GENOFFSETS) \ Makefile.vex.am-93- $(LIBVEX_CFLAGS_NO_LTO) \ Makefile.vex.am-94- $(AM_CFLAGS_@VGCONF_PLATFORM_PRI_CAPS@) \ Makefile.vex.am:95: -O -S -o auxprogs/genoffsets.s \ Makefile.vex.am-96- $(srcdir)/auxprogs/genoffsets.c Makefile.vex.am-97- grep xyzzy auxprogs/genoffsets.s | grep "^[# ]*#define" \ Makefile.vex.am-98-| sed "s/# #define/#define/g" \ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934#c1 suggests that distributions are supposed to install the LTO-plugin on the right place. Do the distrubutuions you care about do so and if not, why? -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 399457] New: Registering at https://identity.kde.org/ does not handle non ASCII names of people
https://bugs.kde.org/show_bug.cgi?id=399457 Bug ID: 399457 Summary: Registering at https://identity.kde.org/ does not handle non ASCII names of people Product: www.kde.org Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kde-...@kde.org Reporter: dilyan.palau...@aegee.org Target Milestone: --- I created at https://identity.kde.org/ an account for me Дилян Палаузов. Then I got an email to confirm. It opens a webpage where I have to select a user name. No user names are offered for choice. If I do not select any user name I cannot continue the process. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 399804] New: Wikipedia: Compare CalDAV and CardDAV support in KDE with other systems
https://bugs.kde.org/show_bug.cgi?id=399804 Bug ID: 399804 Summary: Wikipedia: Compare CalDAV and CardDAV support in KDE with other systems Product: korganizer Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: dilyan.palau...@aegee.org Target Milestone: --- Update at https://en.wikipedia.org/w/index.php?title=Comparison_of_CalDAV_and_CardDAV_implementations#Client_implementations the line about KOrganiser,KAddressbook,Kontact. Possibly add KMail, if this is how iTIP/iMIP messages arrive over mail. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 399804] Wikipedia: Compare CalDAV and CardDAV support in KDE with other systems
https://bugs.kde.org/show_bug.cgi?id=399804 Дилян Палаузов changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|NOT A BUG |--- --- Comment #2 from Дилян Палаузов --- I do not use KDE, I don’t know what to write there and you do not list the supported RFC. It is up to the developers to fill the information there, as it is pretty technical for mortals. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 --- Comment #30 from Дилян Палаузов --- For the record, with /usr/local/etc/config.site containing CC=clang CXX=clang++ CFLAGS="-Wall -pipe -O3" CXXFLAGS="-pipe -O3" LDFLAGS="-L/usr/local/lib64 -Wl,-O1,-s -fuse-ld=gold" and this changes: diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -47,7 +47,7 @@ AC_PROG_CXX AC_PROG_RANLIB # Set LTO_RANLIB variable to an lto enabled ranlib if test "x$LTO_RANLIB" = "x"; then - AC_PATH_PROGS([LTO_RANLIB], [gcc-ranlib]) + AC_PATH_PROGS([LTO_RANLIB], [ranlib]) fi AC_ARG_VAR([LTO_RANLIB],[Library indexer command for link time optimisation]) @@ -68,7 +68,7 @@ AC_ARG_VAR([AR],[Archiver command]) # same for LTO_AR variable for lto enabled archiver if test "x$LTO_AR" = "x"; then - AC_PATH_PROGS([LTO_AR], [gcc-ar]) + AC_PATH_PROGS([LTO_AR], [ar]) fi AC_ARG_VAR([LTO_AR],[Archiver command for link time optimisation]) valgrind does compile and link using clang, after being ./configure'd with --enable-lto. Likewise, having in /usr/local/etc/config.site CFLAGS="-Wall -pipe -O3" CXXFLAGS="-pipe -O3" LDFLAGS="-L/usr/local/lib64 -Wl,-O1,-s -fuse-ld=gold" and thus implicitly using gcc, ./configure --enable-lto also compiles and links. So it is a matter of installing the linker plugin at the right place, uring the installation of the compiler, assuming a recent version of binutils (I think the support for linker plugins is there for 3-4 years now). If the compilers' linker plugins are not installed where the linker+ar+nm+ranlib searches them, consider asking your distribution to do so. I use clang 6.0.0 and have not run any tests. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395682] New: Reading debug info
https://bugs.kde.org/show_bug.cgi?id=395682
Bug ID: 395682
Summary: Reading debug info
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: dilyan.palau...@aegee.org
Target Milestone: ---
Created attachment 113482
--> https://bugs.kde.org/attachment.cgi?id=113482&action=edit
The produced binary
I have this program:
#include
int main() {
printf("a\n");
int i = 7 /0;
printf("b\n");
}
which I compile with "gcc -g t.c -o t"
Running `valgrind -v --memcheck:track-origins=yes --read-var-info=yes
--memcheck:show-leak-kinds=all --vgdb=no t` I expect to see the line where
there are problems, but it prints:
==24781== Memcheck, a memory error detector
==24781== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24781== Using Valgrind-3.14.0.GIT-90daa486e8-20180620X and LibVEX; rerun with
-h for copyright info
==24781== Command: t
==24781==
--24781-- Valgrind options:
--24781---v
--24781----memcheck:track-origins=yes
--24781----read-var-info=yes
--24781----memcheck:show-leak-kinds=all
--24781----vgdb=no
--24781-- Contents of /proc/version:
--24781-- Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
--24781--
--24781-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-sse3
--24781-- Page sizes: currently 4096, max supported 4096
--24781-- Valgrind library directory: /usr/local/lib/valgrind
--24781-- Reading syms from /home/me/t
--24781-- ELF section outside all mapped regions
--24781-- Reading syms from /lib/x86_64-linux-gnu/ld-2.19.so
--24781-- Considering /lib/x86_64-linux-gnu/ld-2.19.so ..
--24781-- .. CRC mismatch (computed c067370a wanted 8c45d3ea)
--24781-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so ..
--24781-- .. CRC is valid
--24781-- warning: addVar: unknown size (buf)
--24781-- warning: addVar: unknown size (buf)
--24781-- warning: addVar: unknown size (buf)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- warning: addVar: unknown size (loadcmds)
--24781-- Reading syms from /usr/local/lib/valgrind/memcheck-amd64-linux
--24781--object doesn't have a symbol table
--24781--object doesn't have a dynamic symbol table
--24781-- Scheduler: using generic scheduler lock implementation.
--24781-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--24781-- REDIR: 0x4017b50 (ld-linux-x86-64.so.2:strlen) redirected to
0x581df42e (???)
--24781-- REDIR: 0x4017900 (ld-linux-x86-64.so.2:index) redirected to
0x581df448 (???)
--24781-- Reading syms from
/usr/local/lib/valgrind/vgpreload_core-amd64-linux.so
--24781--object doesn't have a symbol table
--24781-- Reading syms from
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--24781--object doesn't have a symbol table
==24781== WARNING: new redirection conflicts with existing -- ignoring it
--24781-- old: 0x04017b50 (strlen ) R-> (.0) 0x581df42e
???
--24781-- new: 0x04017b50 (strlen ) R-> (2007.0) 0x0402d490
strlen
--24781-- REDIR: 0x4017b20 (ld-linux-x86-64.so.2:strcmp) redirected to
0x402ed40 (strcmp)
--24781-- REDIR: 0x4018850 (ld-linux-x86-64.so.2:mempcpy) redirected to
0x4037390 (mempcpy)
--24781-- Reading syms from /lib/x86_64-linux-gnu/libc-2.19.so
--24781-- Considering /lib/x86_64-linux-gnu/libc-2.19.so ..
--24781-- .. CRC mismatch (computed 8b555f82 wanted cd9b3228)
--24781-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so ..
--24781-- .. CRC is valid
--24781-- REDIR: 0x4aa8dc0 (libc.so.6:strcasecmp) redirected to 0x4023720
(_vgnU_ifunc_wrapper)
--24781-- REDIR: 0x4aab0b0 (libc.so.6:strncasecmp) redirected to 0x4023720
(_vgnU_ifunc_wrapper)
--24781-- REDIR: 0x4aa8590 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to
0x4023720 (_vgnU_ifunc_wrapper)
--24781-- REDIR: 0x4aa6910 (libc.so.6:rindex) redirected to 0x402ce10 (rindex)
--24781-- REDIR: 0x4aa4c10 (libc.so.6:strlen) redirected to 0x402d3d0 (strlen)
==24781==
==24781== Process terminating with default action of signal 8 (SIGFPE)
==24781== Integer divide by zero at address 0x10090584FE
==24781==at 0x401149: ??? (in /home/me/t)
==24781==by 0x4A44B44: (below main) (libc-start.c:287)
a
--24781-- REDIR: 0x4a9f600 (libc.so.6:free) redirected to 0x402afd0 (free)
==24781==
==24781== HEAP SUMMARY:
==24781== in use at exit: 0 bytes in 0 blocks
==24781== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==24781==
==24781== All
[valgrind] [Bug 386318] New: valgrind.org/info/tools.html is missing SGCheck
https://bugs.kde.org/show_bug.cgi?id=386318 Bug ID: 386318 Summary: valgrind.org/info/tools.html is missing SGCheck Product: valgrind Version: unspecified Platform: Other OS: All Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: dilyan.palau...@aegee.org Target Milestone: --- Insert at http://valgrind.org/info/tools.html links to DHAD, SGCheck and BBV. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386318] valgrind.org/info/tools.html is missing SGCheck
https://bugs.kde.org/show_bug.cgi?id=386318 --- Comment #2 from Дилян Палаузов --- Add at http://valgrind.org/info/tools.html before "Other tools": Experimental tools DHAT DHAT is a tool for examining how programs use their heap allocations. It tracks the allocated blocks, and inspects every memory access to find which block, if any, it is to. BBV A basic block is a linear section of code with one entry point and one exit point. A basic block vector (BBV) is a list of all basic blocks entered during program execution, and a count of how many times each basic block was run. BBV is a tool that generates basic block vectors for use with the SimPoint analysis tool. SGCheck SGCheck is a tool for finding overruns of stack and global arrays. It works by using a heuristic approach derived from an observation about the likely forms of stack and global array accesses. -- You are receiving this mail because: You are watching all bug changes.
