|
From: Patrick O. <pat...@gm...> - 2011-04-20 08:20:11
|
Hello!
Has anyone else tried valgrind in combination with LLVM/clang as
compiler?
I use valgrind-3.6.0.SVN-Debian on Debian Stable/Testing in 64 bit mode,
with C/C++ code compiled with LLVM/clang 2.9. There are some kinks:
* Line information is missing in valgrind report. That works when
compiling with gcc.
* clang complains about "return value not ignored as it should be"
when using the client request macros in the code (-Wall
-Werror).
I can provide more information, but first wanted to hear whether these
might be known issues. A Google and mailing list search didn't produce
any hits.
--
Bye, Patrick Ohly
--
Pat...@gm...
http://www.estamos.de/
|
|
From: Julian S. <js...@ac...> - 2011-04-20 08:36:09
|
> * Line information is missing in valgrind report. That works when > compiling with gcc. Yes, I noticed that too. I haven't investigated. btw, you should have a look at https://bugs.kde.org/show_bug.cgi?id=242137, which is also related to a LLVM+Valgrind issue. > * clang complains about "return value not ignored as it should be" > when using the client request macros in the code (-Wall > -Werror). Does that still happen with a Valgrind svn trunk build? I thought Bart did some fixes in that area. Or proposed some fixes. Or something like that. J |
|
From: Bart V. A. <bva...@ac...> - 2011-04-20 10:03:58
|
On Wed, Apr 20, 2011 at 10:35 AM, Julian Seward <js...@ac...> wrote: > > > * Line information is missing in valgrind report. That works when > > compiling with gcc. > > Yes, I noticed that too. I haven't investigated. btw, you should > have a look at https://bugs.kde.org/show_bug.cgi?id=242137, > which is also related to a LLVM+Valgrind issue. > > > * clang complains about "return value not ignored as it should be" > > when using the client request macros in the code (-Wall > > -Werror). > > Does that still happen with a Valgrind svn trunk build? I thought Bart > did some fixes in that area. Or proposed some fixes. Or something like > that. The patch attached to https://bugs.kde.org/show_bug.cgi?id=242137 still triggers "return value not ignored as it should be" with gcc 4.4 and before. I'll update that patch such that these warnings are gone too. Bart. |
|
From: Julian S. <js...@ac...> - 2011-04-20 15:46:32
|
On Wednesday, April 20, 2011, Patrick Ohly wrote:
> I use valgrind-3.6.0.SVN-Debian on Debian Stable/Testing in 64 bit mode,
> with C/C++ code compiled with LLVM/clang 2.9. There are some kinks:
>
> * Line information is missing in valgrind report. That works when
> compiling with gcc.
Try the patch below. It fixes it for me. The only change is the case
for FORM_addr; all the rest is cosmetic. (That might make it easier to
apply the patch by hand).
J
Index: coregrind/m_debuginfo/readdwarf.c
===================================================================
--- coregrind/m_debuginfo/readdwarf.c (revision 11703)
+++ coregrind/m_debuginfo/readdwarf.c (working copy)
@@ -1079,6 +1079,9 @@
/* TJH 27 Apr 10: in DWARF 4 lineptr (and loclistptr,macptr,
rangelistptr classes) use FORM_sec_offset which is 64 bits
in 64 bit DWARF and 32 bits in 32 bit DWARF. */
+ /* JRS 20 Apr 11: LLVM-2.9 encodes DW_AT_stmt_list using
+ FORM_addr rather than the FORM_data4 that GCC uses. Hence
+ handle FORM_addr too. */
switch( form ) {
/* Those cases extract the data properly */
case 0x05: /* FORM_data2 */ cval = *((UShort*)p); p +=2;
break;
@@ -1101,13 +1104,24 @@
} else {
cval = *((UInt*)p); p += 4;
}; break;
+
+ case 0x07: /* FORM_data8 */ if (ui->dw64) cval =
*((ULong*)p);
+ p += 8; break;
+ /* perhaps should assign
+ unconditionally to cval? */
+
+ case 0x01: /* FORM_addr */ if (addr_size == 4) {
+ cval = *(UInt*)p;
+ } else if (addr_size == 8) {
+ cval = *(ULong*)p;
+ } else {
+ /* wtf, Houston? */
+ }
+ p += addr_size; break;
+
/* TODO : Following ones just skip data - implement if you need
*/
- case 0x01: /* FORM_addr */ p += addr_size; break;
case 0x03: /* FORM_block2 */ p += *((UShort*)p) + 2; break;
case 0x04: /* FORM_block4 */ p += *((UInt*)p) + 4; break;
- case 0x07: /* FORM_data8 */ if (ui->dw64) cval =
*((ULong*)p);
- p += 8; break;
- /* perhaps should assign unconditionally to cval? */
case 0x09: /* FORM_block */ p += read_leb128U( &p ); break;
case 0x0a: /* FORM_block1 */ p += *p + 1; break;
case 0x0c: /* FORM_flag */ p++; break;
|
|
From: Julian S. <js...@ac...> - 2011-04-21 08:57:13
|
> > with C/C++ code compiled with LLVM/clang 2.9. There are some kinks: > > * Line information is missing in valgrind report. That works when > > compiling with gcc. > > Try the patch below. It fixes it for me. Committed as r11705. J |
|
From: Patrick O. <pat...@gm...> - 2011-04-21 12:53:17
|
On Do, 2011-04-21 at 10:56 +0200, Julian Seward wrote: > > > with C/C++ code compiled with LLVM/clang 2.9. There are some kinks: > > > * Line information is missing in valgrind report. That works when > > > compiling with gcc. > > > > Try the patch below. It fixes it for me. > > Committed as r11705. Better late than never: I can confirm that Trunk now works with clang 2.9 debug infos for me. Thanks! On Mi, 2011-04-20 at 10:35 +0200, Julian Seward wrote: > > * clang complains about "return value not ignored as it should be" > > when using the client request macros in the code (-Wall > > -Werror). > > Does that still happen with a Valgrind svn trunk build? I thought Bart > did some fixes in that area. Or proposed some fixes. Or something like > that. Yes, that still happens. I'm not seeing a suitable patch in https://bugs.kde.org/show_bug.cgi?id=242137 either - wrong issue? -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
|
From: Bart V. A. <bva...@ac...> - 2011-04-25 12:44:55
|
On Thu, Apr 21, 2011 at 2:53 PM, Patrick Ohly <pat...@gm...> wrote: > > On Mi, 2011-04-20 at 10:35 +0200, Julian Seward wrote: > > > * clang complains about "return value not ignored as it should be" > > > when using the client request macros in the code (-Wall > > > -Werror). > > > > Does that still happen with a Valgrind svn trunk build? I thought Bart > > did some fixes in that area. Or proposed some fixes. Or something like > > that. > > Yes, that still happens. I'm not seeing a suitable patch in > https://bugs.kde.org/show_bug.cgi?id=242137 either - wrong issue? That patch has been attached to this issue: https://bugs.kde.org/show_bug.cgi?id=269778. Feedback is welcome. Bart. |