valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing

[Florian K. <fl...@ei...>]

On 03.09.2014 19:02, Florian Krohm wrote:
> On 03.09.2014 13:03, Julian Seward wrote:
>>
>> A beta tarball for 3.10.0 is available now at
>> http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2
>> (md5sum = dee188c79a9795fee178ba17f42c40b3)
> 
> I just tested this on my x86-64. I see one unexpected failure in the
> testsuite:
> 
> helgrind/tests/hg05_race2
> fails like so:
> 
> --- hg05_race2.stderr.exp       2014-09-02 12:32:36.000000000 +0200
> +++ hg05_race2.stderr.out       2014-09-03 17:47:06.739851222 +0200
> @@ -26,8 +26,7 @@
>     at 0x........: th (hg05_race2.c:17)
>     by 0x........: mythread_wrapper (hg_intercepts.c:...)
>     ...
> - Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
> - declared at hg05_race2.c:24, in frame #x of thread x
> + Address 0x........ is on thread #x's stack
> 
>  ----------------------------------------------------------------
> 
> @@ -42,8 +41,7 @@
>     at 0x........: th (hg05_race2.c:17)
>     by 0x........: mythread_wrapper (hg_intercepts.c:...)
>     ...
> - Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
> - declared at hg05_race2.c:24, in frame #x of thread x
> + Address 0x........ is on thread #x's stack
> 
> 
> THis is with gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2.  Is this a known issue?


I reran the regtest and this time the test passed. That does not sound
good. Looks like I should run memcheck on helgrind....

   Florian

Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing

[Florian K. <fl...@ei...>]

On 03.09.2014 13:03, Julian Seward wrote:
> 
> A beta tarball for 3.10.0 is available now at
> http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2
> (md5sum = dee188c79a9795fee178ba17f42c40b3)

I just tested this on my x86-64. I see one unexpected failure in the
testsuite:

helgrind/tests/hg05_race2
fails like so:

--- hg05_race2.stderr.exp       2014-09-02 12:32:36.000000000 +0200
+++ hg05_race2.stderr.out       2014-09-03 17:47:06.739851222 +0200
@@ -26,8 +26,7 @@
    at 0x........: th (hg05_race2.c:17)
    by 0x........: mythread_wrapper (hg_intercepts.c:...)
    ...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack

 ----------------------------------------------------------------

@@ -42,8 +41,7 @@
    at 0x........: th (hg05_race2.c:17)
    by 0x........: mythread_wrapper (hg_intercepts.c:...)
    ...
- Location 0x........ is 0 bytes inside foo.poot[5].plop[11],
- declared at hg05_race2.c:24, in frame #x of thread x
+ Address 0x........ is on thread #x's stack


THis is with gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2.  Is this a known issue?

   Florian

Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing

[Phil L. <plo...@sa...>]

Is more information available about these changes?  I'd like to see more detail on "improved error messages" and "stack traces through inlined function calls".

-----Original Message-----
From: Julian Seward [mailto:js...@ac...] 
Sent: Wednesday, September 03, 2014 7:04 AM
To: Val...@li...
Subject: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing


A beta tarball for 3.10.0 is available now at
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2
(md5sum = dee188c79a9795fee178ba17f42c40b3)

Please give it a try in configurations that are important for you, and report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

If nothing critical emerges, a final release is likely to happen late next week.

For details about what's new in 3.10, see the NEWS file in the tarball.  Some of the highlights are:

- Initial support for AArch64 ARMv8 (64-bit ARM)
- 64-bit LE POWER Architecture support
- much improved MacOSX 10.9 support
- MIPS32 support for Android
- stack traces through inlined function calls
- EXIDX unwinding on ARM
- Improved error messages for Memcheck and Helgrind
- Reduced memory use for storing debug info
- A huge number of bug fixes

J


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind-3.10.0 BETA is available for testing

[Julian S. <js...@ac...>]

A beta tarball for 3.10.0 is available now at
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2
(md5sum = dee188c79a9795fee178ba17f42c40b3)

Please give it a try in configurations that are important for you, and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind

If nothing critical emerges, a final release is likely to happen late
next week.

For details about what's new in 3.10, see the NEWS file in the
tarball.  Some of the highlights are:

- Initial support for AArch64 ARMv8 (64-bit ARM)
- 64-bit LE POWER Architecture support
- much improved MacOSX 10.9 support
- MIPS32 support for Android
- stack traces through inlined function calls
- EXIDX unwinding on ARM
- Improved error messages for Memcheck and Helgrind
- Reduced memory use for storing debug info
- A huge number of bug fixes

J

Re: [Valgrind-users] Problem building ppc64 tests due to altivec flag...

[Anmol P. <An...@fr...>]

Thank you, Florian. I'll test it out on an e5500 and update the bug entry with the results.
Regards,
Anmol.


-----Original Message-----
From: Florian Krohm [mailto:fl...@ei...] 
Sent: Monday, September 01, 2014 9:30 AM
To: Bob Cochran; val...@li...
Subject: Re: [Valgrind-users] Problem building ppc64 tests due to altivec flag...

This is a bug. I've opened https://bugs.kde.org/show_bug.cgi?id=338731
There is a patch attached to that bug that should fix the build issue.
It would be good if you could try it out. And even better if you could run this command

perl tests/vg_regtest none/tests/ppc64

afterwards.

   Florian


On 01.09.2014 06:35, Bob Cochran wrote:
> Hello,
> 
> I was cross compiling valgrind tonight using OpenEmbbeded and ran into 
> an error during the compilation of none/tests/ppc64/jm-insns.c.
> 
> Although configure correctly determined that my Freescale T1040 
> (E5500) doesn't support Altivec, the Makefile in none/tests/ppc64 
> appears to have -maltivec hardcoded for jm_insns_CFLAGS.
> 
> Compiling failed when GCC was passed -maltivec.
> 
> I patched out the altivec flag in the Makefile, and my valgrind 
> packages finished building (won't try the test suite any time soon).
> 
>  From searching, I see that there have been Altivec issues in the 
> past, but I didn't see this particular issue come up.  Can I get some 
> guidance on whether this is a bug in the Makefile or whether it's 
> something that I should be avoiding if I had configured things differently?
> 
> Thanks
> 
> Bob
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------
> --------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problem building ppc64 tests due to altivec flag...

[Florian K. <fl...@ei...>]

This is a bug. I've opened https://bugs.kde.org/show_bug.cgi?id=338731
There is a patch attached to that bug that should fix the build issue.
It would be good if you could try it out. And even better if you could
run this command

perl tests/vg_regtest none/tests/ppc64

afterwards.

   Florian


On 01.09.2014 06:35, Bob Cochran wrote:
> Hello,
> 
> I was cross compiling valgrind tonight using OpenEmbbeded and ran into 
> an error during the compilation of none/tests/ppc64/jm-insns.c.
> 
> Although configure correctly determined that my Freescale T1040 (E5500) 
> doesn't support Altivec, the Makefile in none/tests/ppc64 appears to 
> have -maltivec hardcoded for jm_insns_CFLAGS.
> 
> Compiling failed when GCC was passed -maltivec.
> 
> I patched out the altivec flag in the Makefile, and my valgrind packages 
> finished building (won't try the test suite any time soon).
> 
>  From searching, I see that there have been Altivec issues in the past, 
> but I didn't see this particular issue come up.  Can I get some guidance 
> on whether this is a bug in the Makefile or whether it's something that 
> I should be avoiding if I had configured things differently?
> 
> Thanks
> 
> Bob
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

[Valgrind-users] Problem building ppc64 tests due to altivec flag...

[Bob C. <dev...@mi...>]

Hello,

I was cross compiling valgrind tonight using OpenEmbbeded and ran into 
an error during the compilation of none/tests/ppc64/jm-insns.c.

Although configure correctly determined that my Freescale T1040 (E5500) 
doesn't support Altivec, the Makefile in none/tests/ppc64 appears to 
have -maltivec hardcoded for jm_insns_CFLAGS.

Compiling failed when GCC was passed -maltivec.

I patched out the altivec flag in the Makefile, and my valgrind packages 
finished building (won't try the test suite any time soon).

 From searching, I see that there have been Altivec issues in the past, 
but I didn't see this particular issue come up.  Can I get some guidance 
on whether this is a bug in the Makefile or whether it's something that 
I should be avoiding if I had configured things differently?

Thanks

Bob

Re: [Valgrind-users] [Callgrind] jcnd in char array initialization

[Skarakis, K. <kon...@un...>]

So I guess there is a bug in the compiler we use. Maybe I should try to modify Meyer's tool to ignore all "same-line" jumps in the same way as QKachegrind does.


Thank you,
Costas Skarakis

-----Original Message-----
From: Eliot Moss [mailto:mo...@cs...] 
Sent: Monday, August 25, 2014 4:06 PM
To: Skarakis, Konstantinos; val...@li...
Subject: Re: [Valgrind-users] [Callgrind] jcnd in char array initialization

It appears to me that the compiler is writing to all bytes of the string in a loop, as opposed to simply writing a 0x0 to the first byte.

Regards -- Eliot Moss

Re: [Valgrind-users] [Callgrind] jcnd in char array initialization

[Eliot M. <mo...@cs...>]

It appears to me that the compiler is writing
to all bytes of the string in a loop, as opposed
to simply writing a 0x0 to the first byte.

Regards -- Eliot Moss

[Valgrind-users] [Callgrind] jcnd in char array initialization

[Skarakis, K. <kon...@un...>]

Hello,

I am running callgrind with --collect-jumps=yes. I want to parse the callgrind out-files to generate coverage reports. I am getting many conditional jumps that I don't understand though. For instance this line is reported as a conditional jump:

      char host[USC_STRING_LENGTH]="";

The callgrind out-file section for this line is:

0x406460 46 1
0x40646b 46 1
0x406472 46 1
0x406479 46 1
0x406484 46 1
0x406489 46 1
0x40648c 46 1
0x40648e 46 1
0x406499 46 1
0x4064a0 46 1
0x4064a7 46 1
0x4064ae 46 1
jcnd=1/1 0x4064ae 46
0x4064ae 46
0x4064ae 46 15
jcnd=14/15 0x4064ae 46
0x4064ae 46


In source view in QCachegrind it suppresses this jump (I read it does that for all "same-line" or "next-line" jumps) but in assembly view it confirms this as a jump:

40 6460     48 c7 85 90 fe ff ff    movq  $0x0,-0x170(%rbp)
40 6467     00 00 00 00
40 646B     48 8d 85 98 fe ff ff    lea   -0x168(%rbp),%rax
40 6472     48 89 85 b0 48 ff ff    mov   %rax,-0xb750(%rbp)
40 6479     48 c7 85 a8 48 ff ff    movq  $0x0,-0xb758(%rbp)
40 6480     00 00 00 00
40 6484     b8 78 00 00 00          mov   $0x78,%eax
40 6489     83 f8 08          cmp   $0x8,%eax
40 648C     72 23             jb    <main+0x207>
40 648E     48 c7 85 a0 48 ff ff    movq  $0xf,-0xb760(%rbp)
40 6495     0f 00 00 00
40 6499     48 8b bd b0 48 ff ff    mov   -0xb750(%rbp),%rdi
40 64A0     48 8b 8d a0 48 ff ff    mov   -0xb760(%rbp),%rcx
40 64A7     48 8b 85 a8 48 ff ff    mov   -0xb758(%rbp),%rax
40 64AE     ┌->f3 48 ab       rep   stos %rax,%es:(%rdi)
            └-                      Jump 15 of 16 times to 0x4064AE

(I hope the ASCII comes out readable)

Can anyone explain why this is a conditional jump?

The source line mentioned above is in the "main" function in file UscFtpLinkTest.cc which includes UscConfiguration.h which includes UscCommon.h which defines the constant as:

int USC_STRING_LENGTH = 128;


I am using Benjamin Meyer's tool (http://benjamin-meyer.blogspot.de/2007/12/valgrind-callgrind-tools-part-3-code.html) to parse the callgrind files and generate coverage reports. It does have a serious bug though with jump coverage calculations and I was wondering if this has anything to do with it.


Thanks in advance,
Costas Skarakis

Re: [Valgrind-users] The syntax of jump and jcnd in callgrind profile files.

[Dan L. <da...@su...>]

On 24 August 2014 17:20, Josef Weidendorfer <Jos...@gm...> wrote:
> Am 23.08.2014 um 14:56 schrieb Dan Liew:
>>> The instruction address you specify below is always the same as the line
>>> number. That makes not much sense. The instruction address is needed
>>> for KCachegrind to show annotated machine code, using "objdump <binary>",
>>> but your example does not specify a binary file using "ob=" anywayl
>>
>> On a slightly related note is it possible to specify an assembly file
>> rather than an object file? For example If I had a C program (say
>> foo.c) and its corresponding LLVM IR (foo.ll). I would like to display
>> both the C source code and the foo.ll file. When I tried using
>> obj=foo.ll however KCachegrind tried using objdump on that file and
>> gave up because foo.ll is just text and not a binary.
>
> Currently there is no such option, and the "instr" subposition was meant
> to be used with objdump.
>
> Perhaps it would be interesting to have a KCachegrind config option
> (or specified in the header of a callgrind file)
> which specifies what to do with a specific subposition type, instead of
> running it through "objdump". Not sure yet what would cover most use
> cases. For you, just the file and line number would be enough?

Sorry. I've probably confused things slightly. For the main project
I'm currently working yes using only the line number is fine because
my interpreter only works at the source level. With your help I now
have jump information being shown correctly in Kcachegrind so I will
definitely be outputting profiling information in the callgrind format
:)

The reason I was asking was because I was looking at another project
(which was what inspired me play with KCachegrind) called KLEE[1].
This tool executes LLVM IR that comes from C programs, so there is an
original source (e.g. foo.c) and the corresponding LLVM IR (e.g.
foo.ll). Both of these are text files and I observed that the
callgrind files that KLEE was emitting set ``ob=`` to the LLVM IR file
and ``fl=`` to the original C source file. As I mentioned before this
doesn't work as the author of KLEE intended because Kcachegrind tries
to treat foo.ll as a object file rather than as a text file.

In this case I like to think of LLVM IR as being similar to assembly
so using the instr subposition with absolute line numbers feels fairly
natural. KCachegrind could be taught to try and infer if ``ob=`` is
really an object file or if it is text by looking for magic numbers
(like the file command does) and then doing the appropriate thing. I
think it would be nicer if the Callgrind file could optionally specify
what to do with the instruction subposition type as you suggested.

Just allowing obj to be plain text might be enough flexibility because
this allows someone who wants to use their own disassembler (e.g.
llvm-objdump) or no disassembler at all to run whatever tools they
want on their object file to produce a text file before profiling.
Then they can use the instruction subposition in the callgrind file
can just refer to lines in this text file. You could have an option
like

# Objects are plain text
obj_is_plain_text=1

in the callgrind file (which is by default 0) to specify that all
object files are plain text files.

You could go further and specify the tool to use for object files in
the callgrind file but then you run into the problem that kcachegrind
might not know how to parse the output so I think just allowing the
object file to be plain text might be the simplest thing to do.

There certainly isn't a rush for the feature like this but I think it
would be a nice addition.

Thanks,
Dan

[1] http://klee.llvm.org

Re: [Valgrind-users] The syntax of jump and jcnd in callgrind profile files.

[Josef W. <Jos...@gm...>]

Am 23.08.2014 um 14:56 schrieb Dan Liew:
>> The instruction address you specify below is always the same as the line
>> number. That makes not much sense. The instruction address is needed
>> for KCachegrind to show annotated machine code, using "objdump <binary>",
>> but your example does not specify a binary file using "ob=" anywayl
> 
> On a slightly related note is it possible to specify an assembly file
> rather than an object file? For example If I had a C program (say
> foo.c) and its corresponding LLVM IR (foo.ll). I would like to display
> both the C source code and the foo.ll file. When I tried using
> obj=foo.ll however KCachegrind tried using objdump on that file and
> gave up because foo.ll is just text and not a binary.

Currently there is no such option, and the "instr" subposition was meant
to be used with objdump.

Perhaps it would be interesting to have a KCachegrind config option
(or specified in the header of a callgrind file)
which specifies what to do with a specific subposition type, instead of
running it through "objdump". Not sure yet what would cover most use
cases. For you, just the file and line number would be enough?

>> ...
> That probably ought to be documented.

Sure. The jumps were one of the last additions to the file format, and
it just never was documented correctly.

> It's not obvious that it is
> needed. I'm also surprised that the position of the jump isn't
> specified on the same line.

I wanted that to be similar to the calls= spec, and was not sure
if some cost attributes may be useful to jumps as well (which currently
is empty).
But details do not matter; documentation is important.

>> By the way, if your jump crosses a source file or a function,
>> you may specify the source file of the jump target with "jfi=" and
>> the target function name with "jfn=" before a the "jump="/"jcnd" line.
> 
> Thanks. Like ``cfn=`` does that change the function that subsequent
> cost lines are in?
> 
> I don't see these in the documentation either so it would be nice if
> they were documented.

See above. Currently the documentation is in the (KCachegrind) source :(

Josef


> 

Re: [Valgrind-users] The syntax of jump and jcnd in callgrind profile files.

[Dan L. <da...@su...>]

Thanks for the prompt response :)

<snip>

>> It's not defined what ``target`` is but after looking at what
>> callgrind produces it seems that is some sort of offset (e.g. +5).
>> What I see produced by callgrind doesn't really seem to match the
>> above.
>
> The "target position" is a "SubPositionList" in the grammar, the
> same as in the beginning of a CostLine. The "positions:" header line
> defines which subpositions there are, and in your example there
> are two: "instr line". The first number is an address for the machine
> code, and the second number is the line in a source file.
> Subpositions can be specified to be relative to the a subposition
> given directly before, by prefixing it with "-" or "+".

Thanks. That makes things significantly clearer.

>> After playing around with a simple profile file and KCacheGrind it
>> seemed that to get what I want (KCachegrind to show jump arrows for my
>> source code without emitting parser warnings) that I had to do this
>>
>> ```
>> positions: instr line
>
> Why not just "positions: line" ?

The reason was that when I tried using just "positions: line" that the
jump= and jcnd= stopped being displayed in KCacheGrind.  Now that
you've explained that "target position" is "SubPositionList" in the
grammar I've managed to use jump= and jcnd= with only using lines and
it works fine :)

> The instruction address you specify below is always the same as the line
> number. That makes not much sense. The instruction address is needed
> for KCachegrind to show annotated machine code, using "objdump <binary>",
> but your example does not specify a binary file using "ob=" anywayl

On a slightly related note is it possible to specify an assembly file
rather than an object file? For example If I had a C program (say
foo.c) and its corresponding LLVM IR (foo.ll). I would like to display
both the C source code and the foo.ll file. When I tried using
obj=foo.ll however KCachegrind tried using objdump on that file and
gave up because foo.ll is just text and not a binary.

>> events: Instructions
>>
>> fl=s.bpl
>> fn=main
>>
>> # Specify cost for jump
>> 14 14 9
>> # Unconditional jump happens 5 times, +1 is a dummy offset, to line 19
>> jump=5 +1 19
>
> "+1" is not a dummy offset, but is the instruction address of the jump
> target, which is relative to the previous position specifed in your
> example in the line above, ie. the first two numbers of "14 14 9".
> Thus, your line is the same as "jump=5 15 19" or "jump=5 +1 +5".

Thanks for explaining that. My comment was actually trying to say I
was considering +1 to be a dummy offset because I didn't care what it
was set.

>> 14 14
>
> Yes. Similar to calls, "jump="/"jcnd=" lines need to be followed by a line
> specifying the source position of the jump.

That probably ought to be documented. It's not obvious that it is
needed. I'm also surprised that the position of the jump isn't
specified on the same line.

> By the way, if your jump crosses a source file or a function,
> you may specify the source file of the jump target with "jfi=" and
> the target function name with "jfn=" before a the "jump="/"jcnd" line.

Thanks. Like ``cfn=`` does that change the function that subsequent
cost lines are in?

I don't see these in the documentation either so it would be nice if
they were documented.

-- 
Dan Liew
PhD Student - Imperial College London

Re: [Valgrind-users] The syntax of jump and jcnd in callgrind profile files.

[Josef W. <Jos...@gm...>]

Am 22.08.2014 um 19:48 schrieb Dan Liew:
> The documentation [1] doesn't define these very clearly. The grammar
> for ``JumpSpecification`` doesn't seem to be specified properly.

Oops, indeed.
Thanks for the notification.


> * jump=count target position [Callgrind]
> 
> Unconditional jump, executed count times, to the given target position.
> 
> * jcnd=exe.count jumpcount target position [Callgrind]
> 
> Conditional jump, executed exe.count times with jumpcount jumps to the
> given target position.
> ```
> 
> It's not defined what ``target`` is but after looking at what
> callgrind produces it seems that is some sort of offset (e.g. +5).
> What I see produced by callgrind doesn't really seem to match the
> above.

The "target position" is a "SubPositionList" in the grammar, the
same as in the beginning of a CostLine. The "positions:" header line
defines which subpositions there are, and in your example there
are two: "instr line". The first number is an address for the machine
code, and the second number is the line in a source file.
Subpositions can be specified to be relative to the a subposition
given directly before, by prefixing it with "-" or "+".

> After playing around with a simple profile file and KCacheGrind it
> seemed that to get what I want (KCachegrind to show jump arrows for my
> source code without emitting parser warnings) that I had to do this
> 
> ```
> positions: instr line

Why not just "positions: line" ?
The instruction address you specify below is always the same as the line
number. That makes not much sense. The instruction address is needed
for KCachegrind to show annotated machine code, using "objdump <binary>",
but your example does not specify a binary file using "ob=" anyway.

> events: Instructions
> 
> fl=s.bpl
> fn=main
> 
> # Specify cost for jump
> 14 14 9
> # Unconditional jump happens 5 times, +1 is a dummy offset, to line 19
> jump=5 +1 19

"+1" is not a dummy offset, but is the instruction address of the jump
target, which is relative to the previous position specifed in your
example in the line above, ie. the first two numbers of "14 14 9".
Thus, your line is the same as "jump=5 15 19" or "jump=5 +1 +5".

> 14 14

Yes. Similar to calls, "jump="/"jcnd=" lines need to be followed by a line
specifying the source position of the jump.

By the way, if your jump crosses a source file or a function,
you may specify the source file of the jump target with "jfi=" and
the target function name with "jfn=" before a the "jump="/"jcnd" line.

> jcnd=<followed_count>/<total_count> <target> <target_line>
> <position>

Better:

=============
jcnd=<followed_count>/<total_count> <jump target position>
<jump source position>
==============

where a <position> is one or two numbers, depending on the "positions:"
header line. If source line numbers are enough for you, just do

==============
positions: line

....

# jump 2 of 8 times, from line 10 to 20
jcnd=1/8 20
10

...
===============


Cheers,
Josef



> ```
> 
> Where:
> <followed_count> - Number of times <target> was followed from this jump
> <total_count> - Number of times this jump was executed
> <target> is ???
> <target_line> - line that this branch from the jump instruction jumps to
> <position> is location of the jump instruction. Note it's on the next
> line after jcnd=
> 
> Is what I've guessed about the syntax correct?
> 
> 
> [1] http://valgrind.org/docs/manual/cl-format.html
> 
> Thanks,
> 

[Valgrind-users] The syntax of jump and jcnd in callgrind profile files.

[Dan L. <da...@su...>]

Hi,

I'm hoping to use the callgrind profile file format for an interpreter
I'm working on so I can visualise various parameters using
KCacheGrind.

So far this has looked very promising but I've run into an issue with
jumps (jump= and jcnd=)

The documentation [1] doesn't define these very clearly. The grammar
for ``JumpSpecification`` doesn't seem to be specified properly.

Later on the docs note the following.

```

* jump=count target position [Callgrind]

Unconditional jump, executed count times, to the given target position.

* jcnd=exe.count jumpcount target position [Callgrind]

Conditional jump, executed exe.count times with jumpcount jumps to the
given target position.
```

It's not defined what ``target`` is but after looking at what
callgrind produces it seems that is some sort of offset (e.g. +5).
What I see produced by callgrind doesn't really seem to match the
above.

After playing around with a simple profile file and KCacheGrind it
seemed that to get what I want (KCachegrind to show jump arrows for my
source code without emitting parser warnings) that I had to do this

```
positions: instr line
events: Instructions

fl=s.bpl
fn=main

# Specify cost for jump
14 14 9
# Unconditional jump happens 5 times, +1 is a dummy offset, to line 19
jump=5 +1 19
14 14

# Specify cost for unconditional jump
21 21 9
# Conditional jump to line 25 happens 1 out of 2 times (+1 is dummy offset)
jcnd=1/2 +1 25
21 21

# Conditional jump to line 27 happens 1 out of 2 times (+1 is dummy offset)
jcnd=1/2 +1 27
21 21
```

So it seems jump the syntax is **actually** something like...

```
jump=<count> <target> <target_line>
<position>
```

Where:
<target> is ???
<target_line> is the line that we will jump to
<position> is the location of the jump instruction. Note it's on the
next line after jump=


and for jcnd the syntax is **actually** something like...

```
jcnd=<followed_count>/<total_count> <target> <target_line>
<position>
```

Where:
<followed_count> - Number of times <target> was followed from this jump
<total_count> - Number of times this jump was executed
<target> is ???
<target_line> - line that this branch from the jump instruction jumps to
<position> is location of the jump instruction. Note it's on the next
line after jcnd=

Is what I've guessed about the syntax correct?


[1] http://valgrind.org/docs/manual/cl-format.html

Thanks,
-- 
Dan Liew
PhD Student - Imperial College London

Re: [Valgrind-users] memory barriers support

[Jan V. <jan...@ni...>]

> > $ ./configure --enable-recvmmsg=no \
> >               --enable-lto=no \
> >               --disable-fastparser \
> >               --disable-shared \
> >               --enable-static
> 
> If you link with a static malloc library, you have to use
> --soname-synonyms=somalloc=NONE
> to have the malloc/free interceptions needed for memcheck, helgrind,
> drd, ... to work properly.

I've verified, that libc is linked dynamically. The --disable-shared applies 
only to our internal libraries. So this should not be the case.

Re: [Valgrind-users] memory barriers support

[Milian W. <ma...@mi...>]

On Wednesday 20 August 2014 01:08:41 Philippe Waroquiers wrote:
> On Tue, 2014-08-19 at 22:29 +0200, Philippe Waroquiers wrote:
> > > It doesn't use __thread anywhere, but rather lets gcc take care of
> > > ensuring
> > > thread-safety on static objects (like C++11 mandates, but it has been
> > > doing so for a long time already).
> > 
> > Quickly re-reading the mail, this is not related.
> > I see that drd has some interceptions that does annotate
> > these like a mutex lock/unlock (see drd/drd_libstdcxx_intercepts.c)
> > and has a test which looks like your problem in
> > drd/tests/local_static.cpp
> > 
> > I think a similar code is (trivially) doable for helgrind,
> > inside helgrind/hg_intercepts.c
> 
> Just tried to do this trivial code.
> But I still had (what looks like) false positive.
> Probably explanation is that these drd intercepts are not working (yet),
> as documented in log for revision 14013:
>   r14013 | bart | 2014-06-09 11:00:42 +0200 (Mon, 09 Jun 2014) | 1 line
> 
>   drd/tests/local_static: Disable because g++ does not yet allow proper
>   interception of initialization of local static variables
> 
> I have no idea what problem/difficulty was encountered.
> 
> What is exactly the semantic of a threadsafe static ?
> I understand it is initialised only once, and that such 'init once'
> is guaranteed thanks to __cxa_guard_acquire/__cxa_guard_release.
> However, what is __cxa_guard_abort used for ?
> 
> Once the object is initialised, I guess it must be either used
> read-only by all threads, or have a classical way to be protected
> (e.g. via a mutex).

Not sure if that helps you, but here's an excerpt from the current version of 
the C++11 standard draf, which you can obtain free-of-charge on isocpp.org 
[1].From §6.7.4 (Declaration statement):

If control enters the declaration concurrently while the variable is being 
initialized, the concurrent execution shall wait for completion of the 
initialization.

The implementation must not introduce any deadlock around execution of the 
initializer.

See also [2] and search for "Using a C++11 Static Initializer".

[1]: https://isocpp.org/std/the-standard
[2]: http://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/

HTH

-- 
Milian Wolff
ma...@mi...
http://milianw.de

Re: [Valgrind-users] memory barriers support

[Philippe W. <phi...@sk...>]

On Tue, 2014-08-19 at 22:29 +0200, Philippe Waroquiers wrote:
> > It doesn't use __thread anywhere, but rather lets gcc take care of ensuring 
> > thread-safety on static objects (like C++11 mandates, but it has been doing so 
> > for a long time already).
> Quickly re-reading the mail, this is not related.
> I see that drd has some interceptions that does annotate
> these like a mutex lock/unlock (see drd/drd_libstdcxx_intercepts.c)
> and has a test which looks like your problem in
> drd/tests/local_static.cpp
> 
> I think a similar code is (trivially) doable for helgrind,
> inside helgrind/hg_intercepts.c
Just tried to do this trivial code.
But I still had (what looks like) false positive.
Probably explanation is that these drd intercepts are not working (yet),
as documented in log for revision 14013:
  r14013 | bart | 2014-06-09 11:00:42 +0200 (Mon, 09 Jun 2014) | 1 line

  drd/tests/local_static: Disable because g++ does not yet allow proper 
  interception of initialization of local static variables

I have no idea what problem/difficulty was encountered.

What is exactly the semantic of a threadsafe static ?
I understand it is initialised only once, and that such 'init once'
is guaranteed thanks to __cxa_guard_acquire/__cxa_guard_release.
However, what is __cxa_guard_abort used for ?

Once the object is initialised, I guess it must be either used
read-only by all threads, or have a classical way to be protected
(e.g. via a mutex).

Philippe

Re: [Valgrind-users] memory barriers support

[Julian S. <js...@ac...>]

On 08/19/2014 02:31 PM, Jan Včelák wrote:
> I believe the problem originates in some kind of race.

Try --fair-sched=yes to see if you can reproduce the problem more
often and/or more reliably.

J

Re: [Valgrind-users] memory barriers support

[Philippe W. <phi...@sk...>]

On Tue, 2014-08-19 at 22:11 +0200, David Faure wrote:
> > > I'm still trying to find a way to annotate threadsafe-statics so that
> > > helgrind doesn't complain about them.
> > 
> > What is a threadsafe-static ?
> 
> See older mail to this list, attached.
> 
> It doesn't use __thread anywhere, but rather lets gcc take care of ensuring 
> thread-safety on static objects (like C++11 mandates, but it has been doing so 
> for a long time already).
Quickly re-reading the mail, this is not related.
I see that drd has some interceptions that does annotate
these like a mutex lock/unlock (see drd/drd_libstdcxx_intercepts.c)
and has a test which looks like your problem in
drd/tests/local_static.cpp

I think a similar code is (trivially) doable for helgrind,
inside helgrind/hg_intercepts.c

> Is that related to nptl (I'm not sure what that is exactly)?
nptl = new posix thread library (not so new now :).
It is just the glibc pthread library.
The kludge I am doing is not related to your problem.

Philippe

Re: [Valgrind-users] memory barriers support

[Alexander P. <gl...@go...>]

On Aug 19, 2014 11:58 PM, "Philippe Waroquiers" <
phi...@sk...> wrote:
>
> On Tue, 2014-08-19 at 21:44 +0200, David Faure wrote:
> > On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote:
> > > On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:
> > > > > ThreadSanitizer won't comprehend the fence instructions inserted
by
> > > > > urcu.
> > > > > I believe even Helgrind won't, because these instructions do not
imply
> > > > > any happens-before relation.
> > > >
> > > > Is there any opensource or commercial tool which might help in such
> > > > situations (e.g. problems with memory barriers) ?
> > >
> > > helgrind or drd or ThreadSanitizer could still be used for race
> > > condition detection but you would have to annotate either the rcu
> > > library or the calling code to describe the happens before
> > > relationships.
> >
> > Are such annotations documented somewhere?
>
http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.client-requests
> gives a list of such annotations, and points to helgrind.h for more
> information.
>
> > I'm still trying to find a way to annotate threadsafe-statics so that
helgrind
> > doesn't complain about them.
> What is a threadsafe-static ?
That's a local static that is guarded by
__cxa_guard_acquire/__cxa_guard_release to ensure it's initialized only
once. Prior to C++11 GCC used to emit those by default, whereas MSVC didn't
support them. C++11 mandates that static initialization must be thread-safe.
>From the data race detector's point of view the guard object is essentially
a lock.
> Is that using __thread in something like:
>   void fun(void)
>   {
>      static __thread int no_race_on_this_var_is_possible;
>      ....
>   }
>
> If that is the case, I am just finishing a change that should avoid
> false positive in __thread variables.
>
> Humph, replace rather 'change' by kludge:
> The user will have to add the option
>      --sim-hints=no-nptl-pthread-stackcache
> and that uses a nasty kludge to disable the nptl pthread stack&tls
> cache, as helgrind does not understand that the memory for e.g.
> tls __thread variables is "safely" re-usable by another thread once the
> thread is finished.
>
> Philippe
>
>
>
>
------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memory barriers support

[David F. <fa...@kd...>]

On Tuesday 19 August 2014 21:57:02 Philippe Waroquiers wrote:
> On Tue, 2014-08-19 at 21:44 +0200, David Faure wrote:
> > On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote:
> > > On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:
> > > > > ThreadSanitizer won't comprehend the fence instructions inserted by
> > > > > urcu.
> > > > > I believe even Helgrind won't, because these instructions do not
> > > > > imply
> > > > > any happens-before relation.
> > > > 
> > > > Is there any opensource or commercial tool which might help in such
> > > > situations (e.g. problems with memory barriers) ?
> > > 
> > > helgrind or drd or ThreadSanitizer could still be used for race
> > > condition detection but you would have to annotate either the rcu
> > > library or the calling code to describe the happens before
> > > relationships.
> > 
> > Are such annotations documented somewhere?
> 
> http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.client-requests
> gives a list of such annotations, and points to helgrind.h for more
> information.

Thanks.

> > I'm still trying to find a way to annotate threadsafe-statics so that
> > helgrind doesn't complain about them.
> 
> What is a threadsafe-static ?

See older mail to this list, attached.

It doesn't use __thread anywhere, but rather lets gcc take care of ensuring 
thread-safety on static objects (like C++11 mandates, but it has been doing so 
for a long time already).

Is that related to nptl (I'm not sure what that is exactly)?

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] memory barriers support

[David F. <fa...@kd...>]

On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote:
> On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:
> > > ThreadSanitizer won't comprehend the fence instructions inserted by
> > > urcu.
> > > I believe even Helgrind won't, because these instructions do not imply
> > > any happens-before relation.
> > 
> > Is there any opensource or commercial tool which might help in such
> > situations (e.g. problems with memory barriers) ?
> 
> helgrind or drd or ThreadSanitizer could still be used for race
> condition detection but you would have to annotate either the rcu
> library or the calling code to describe the happens before
> relationships.

Are such annotations documented somewhere?

I'm still trying to find a way to annotate threadsafe-statics so that helgrind 
doesn't complain about them.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] memory barriers support

[Philippe W. <phi...@sk...>]

On Tue, 2014-08-19 at 21:44 +0200, David Faure wrote:
> On Tuesday 19 August 2014 21:00:58 Philippe Waroquiers wrote:
> > On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:
> > > > ThreadSanitizer won't comprehend the fence instructions inserted by
> > > > urcu.
> > > > I believe even Helgrind won't, because these instructions do not imply
> > > > any happens-before relation.
> > > 
> > > Is there any opensource or commercial tool which might help in such
> > > situations (e.g. problems with memory barriers) ?
> > 
> > helgrind or drd or ThreadSanitizer could still be used for race
> > condition detection but you would have to annotate either the rcu
> > library or the calling code to describe the happens before
> > relationships.
> 
> Are such annotations documented somewhere?
http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.client-requests
gives a list of such annotations, and points to helgrind.h for more
information.

> I'm still trying to find a way to annotate threadsafe-statics so that helgrind 
> doesn't complain about them.
What is a threadsafe-static ?
Is that using __thread in something like:
  void fun(void)
  {
     static __thread int no_race_on_this_var_is_possible;
     ....
  }

If that is the case, I am just finishing a change that should avoid
false positive in __thread variables.

Humph, replace rather 'change' by kludge: 
The user will have to add the option
     --sim-hints=no-nptl-pthread-stackcache
and that uses a nasty kludge to disable the nptl pthread stack&tls
cache, as helgrind does not understand that the memory for e.g.
tls __thread variables is "safely" re-usable by another thread once the
thread is finished.

Philippe

Re: [Valgrind-users] memory barriers support

[Philippe W. <phi...@sk...>]

On Tue, 2014-08-19 at 16:46 +0200, Roland Mainz wrote:

> > ThreadSanitizer won't comprehend the fence instructions inserted by urcu.
> > I believe even Helgrind won't, because these instructions do not imply
> > any happens-before relation.
> 
> Is there any opensource or commercial tool which might help in such
> situations (e.g. problems with memory barriers) ?

helgrind or drd or ThreadSanitizer could still be used for race
condition detection but you would have to annotate either the rcu
library or the calling code to describe the happens before
relationships.

To my knowledge, there is (some?) (source?) compatibility between
the annotations needed for these 3 tools.

Philippe