|
From: Frank C. <fra...@gm...> - 2011-05-24 23:54:12
|
Good afternoon, We are running callgrind and
cg_annotate version 3.6.1
on Centos Linux Version 5.5 x86_32. One month ago Mr. Josef Weidenorfer
issued a special patch that fixed callgrind on Centos Linux Version
5.5 x86_32. We can now profile complex C++ programs which use our own
shared library libmdMatchup.so.
However, when we use version 3.6.1 cg_annotate
callgrind.out.22533 --auto = yes
-I/home/frankc/DQTTest6/MatchUpLib/Source, we obtain the error. Line
1 Missing command line. callgrind.out.22533 was
created using the command line:
/home/frankc/DQTTest2/valgrind-3.6.1/coregrind/valgrind
--tool=callgrind --dump-instr=yes --simulate-cache=yes
--collect-jumps=yes ./MatchUpAccurate.exe. MatchUpAccurate.exe uses a
special shared library libmdMatchup.so
Could some engineer or programmer please tell us what we are
doing wrong in using
callgrind and cg_annotate? Please let us know ifother
programmers/developers have been able to use cg_annotate version 3.6.1
on Centos Linux Version 5.5 x86_32. I am including the top 50 lines of
Callgrind.out.22533 below in case you have time to look at our
problem.
Thank you.
version: 1
creator: callgrind-3.6.1
pid: 22533
cmd: ./MatchUpAccurate.exe
part: 1
desc: I1 cache: 16384 B, 32 B, 8-way associative
desc: D1 cache: 8192 B, 64 B, 4-way associative
desc: LL cache: 524288 B, 64 B, 8-way associative
desc: Timerange: Basic block 0 - 10444424808
desc: Trigger: Program termination
positions: instr line
events: Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw
summary: 51414468282 24200786461 13006654839 651776228 364795898
154843814 202585 5324012 59432151
ob=(10) /home/frankc/DQTTest6/MatchUpTest/lirh5g_deb/MatchUpAccurate.exe
fl=(20) /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream
fn=(8384) __tcf_0
0x804e2d8 76 1 0 1 1 0 0 1
+1 * 1
+2 * 1 0 1
+1 * 1
+3 * 1 0 1 1
cfi=(14) ???
cfn=(1026) 0x0804f422
calls=1 0x804f422 -76
* * 2 2
+5 * 1
+6 * 1
+6 * 1 0 1
+3 * 1 0 1
cob=(7) /usr/lib/libstdc++.so.6.0.8
cfi=(7) ???
cfn=(8390) std::ios_base::Init::~Init()
calls=1 0x3e30b70 -76
* * 26 12 8 5 3 0 4 3
cob=(1) /lib/ld-2.5.so
cfi=(1) ???
cfn=(176) _dl_runtime_resolve
calls=1 0xae7440 -76
* * 1428 508 202 3 40 5 0 16 3
* * 5 3 2 1 2
+5 * 1
+3 * 1 1
+1 * 1 1
+1 * 1 1
fl=(27) /usr/include/sys/stat.h
fn=(1290) fstat
0x80517e8 448 18 0 18 18 0 0 3
+1 * 18
+2 * 18 0 18
|
|
From: Josef W. <Jos...@gm...> - 2011-05-25 08:06:54
|
Hi, On Wednesday 25 May 2011, Frank Chang wrote: > Good afternoon, We are running callgrind and > cg_annotate version 3.6.1 You need to use callgrind_annotate. cg_annotate is the tool for cachegrind output. The naming is a little bit unfortunate. Josef |
|
From: Florian K. <br...@ac...> - 2011-05-25 15:10:37
|
On 05/25/2011 04:06 AM, Josef Weidendorfer wrote: > > You need to use callgrind_annotate. > cg_annotate is the tool for cachegrind output. > > The naming is a little bit unfortunate. > Definitely. How about renaming cg_annotate to cachegrind_annotate? In the presence of shells doing command completion the extra typing burden is quite contained. We can keep cg_annotate around for another release but deprecate it. Then it can be removed in the release after next. Florian |
|
From: Josef W. <Jos...@gm...> - 2011-05-25 16:00:01
|
On Wednesday 25 May 2011, Florian Krohm wrote: > On 05/25/2011 04:06 AM, Josef Weidendorfer wrote: > > > > You need to use callgrind_annotate. > > cg_annotate is the tool for cachegrind output. > > > > The naming is a little bit unfortunate. > > > > Definitely. How about renaming cg_annotate to cachegrind_annotate? Sounds reasonable. Julian? > In the presence of shells doing command completion the extra typing > burden is quite contained. We can keep cg_annotate around for another > release but deprecate it. Then it can be removed in the release after next. > > Florian > |
|
From: Julian S. <js...@ac...> - 2011-05-27 13:08:30
|
On Wednesday, May 25, 2011, Josef Weidendorfer wrote: > On Wednesday 25 May 2011, Florian Krohm wrote: > > On 05/25/2011 04:06 AM, Josef Weidendorfer wrote: > > > You need to use callgrind_annotate. > > > cg_annotate is the tool for cachegrind output. > > > > > > The naming is a little bit unfortunate. > > > > Definitely. How about renaming cg_annotate to cachegrind_annotate? > > Sounds reasonable. Julian? This a decision for Nick, not me. > > In the presence of shells doing command completion the extra typing > > burden is quite contained. We can keep cg_annotate around for another > > release but deprecate it. Then it can be removed in the release after > > next. For sure we'd need this backward-compatibility hack for a while, yes. J |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-05-27 15:06:40
|
>> > > cg_annotate is the tool for cachegrind output.
>> > > The naming is a little bit unfortunate.
>> > Definitely. How about renaming cg_annotate to cachegrind_annotate?
With the introduction of the gdbserver in Valgrind (3.7.0 svn), the
'cg' prefix (for cachegrind) versus 'ct' prefix (for callgrind) is also
visible in the gdbserver monitor commands.
E.g. to ask callgrind to do a dump, the following is done from gdb:
(gdb) monitor ct.dump
or from a shell:
vgdb ct.dump
So, as you see, for callgrind, we need to type prefix 'ct'.
The above naming schema is based on:
* gdb will complete its "own" command (e.g. mo <tab> will be completed to monitor)
but gdb can't complete what follows monitor.
* the "two letters" code of a tool was used as a short unambiguous prefix.
Currently, we have:
memcheck => mc
massif => ms
callgrind => ct (this comes from the old "calltree" callgrind name)
Following the same logic, if we would have monitor commands for cachegrind,
they would start with cg. (there are no cachegrind monitor command at this stage).
Changing in gdbserver the two letters for callgrind is very easy at this stage
(as nobody is yet depending on these letters, it is only in Valgrind svn 3.7.0).
But if we better change these, what should these 2 letters be ?
Philippe
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
From: Josef W. <Jos...@gm...> - 2011-05-27 17:22:30
|
On Friday 27 May 2011, WAROQUIERS Philippe wrote:
> callgrind => ct (this comes from the old "calltree" callgrind name)
Yes.
However, I really dislike the old name "calltree", as the information collected
by callgrind never was a tree (and never will be), but is a call graph. That was
the reason to rename it years ago.
> Following the same logic, if we would have monitor commands for cachegrind,
> they would start with cg. (there are no cachegrind monitor command at this stage).
Sure. "cg" should be reserved for cachegrind. Everything else would increase confusion.
> Changing in gdbserver the two letters for callgrind is very easy at this stage
> (as nobody is yet depending on these letters, it is only in Valgrind svn 3.7.0).
>
> But if we better change these, what should these 2 letters be ?
Is there a need for vgdb to stick with 2 letters? I much would prefer "clg"
instead. Since years I use the alias clg='valgrind --tool=callgrind', and in
the callgrind sources I use the CLG_ prefix quite often.
For the original matter of this thread, I can imagine a rename from
callgrind_{annotate,control} to clg_{annotate,control}, but not sure that
would have helped the original poster.
Anyway, for a 2-letter option, "cl" seems a lot better than "ct" for me.
Josef
|
|
From: Florian K. <br...@ac...> - 2011-05-27 22:58:34
|
On 05/27/2011 01:22 PM, Josef Weidendorfer wrote: > On Friday 27 May 2011, WAROQUIERS Philippe wrote: > >> Changing in gdbserver the two letters for callgrind is very easy at this stage >> (as nobody is yet depending on these letters, it is only in Valgrind svn 3.7.0). >> Good. >> But if we better change these, what should these 2 letters be ? > > Is there a need for vgdb to stick with 2 letters? I much would prefer "clg" > instead. Since years I use the alias clg='valgrind --tool=callgrind', and in > the callgrind sources I use the CLG_ prefix quite often. > I agree with Josef it would be best if we could drop the 2-letter-acronym requirement. My preference would be to use the tool name instead (and not some form of abbreviation). That increases usability as it eliminates all confusion. I fail to see the value of having to use an abbreviated tool name in certain contexts. It's just one more thing to remember. And it's not clear to me what the value is in return. Florian |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-05-28 11:19:07
|
>> Is there a need for vgdb to stick with 2 letters? I much would prefer "clg"
>> instead. Since years I use the alias clg='valgrind --tool=callgrind', and in
>> the callgrind sources I use the CLG_ prefix quite often.
>>
>
>I agree with Josef it would be best if we could drop the
>2-letter-acronym requirement. My preference would be to use the tool
>name instead (and not some form of abbreviation). That increases
>usability as it eliminates all confusion. I fail to see the value of
>having to use an abbreviated tool name in certain contexts. It's just
>one more thing to remember. And it's not clear to me what the value is
>in return.
The 2 letters is just a convention, we can use more letters.
The only "requirement" are:
* it should be non-ambiguous, i.e. it is better to have
a command for a certain tool to not be confused with a command
from another tool or with a standard core valgrind command.
So, the idea was that standard core commands are starting
with vg. while tool commands starts with their own unique
prefix (e.g. mc. ms. and the to be chosen for callgrind).
* It should not be to long to type: gdb monitor command
does not have completion for its arguments.
e.g. to get the v bits for 8 bytes at addr 0x1234
I prefer to type (gdb) mo mc.g 0x1234 8
than mo memcheck.g 0x1234 8
mo is extended by gdb as monitor
the .g is sufficient for gdbserver memcheck code
to disambiguate if there is only one memcheck command
starting with the same letter which I have ensured
up to now for most(all?) command and most(all?) of their
arguments.
The main reason to have short prefix is that that such commands
are typed often, and the prefix must be typed in full.
So, for callgrind, we can use clg. as suggested by Josef
or use cl or ...
I would not like long commands (and/or long arguments that are
ambiguous unless you type many of the leading characters).
But if I am in the very few that likes short things to type, I can
survive with long prefixes and start typing
list-files-in-directories --output-long-format-with-dates :).
(of course, I like a lot the gnu convention to have both short and
long option names, but that looks an overkill for gdbsrv in valgrind).
Philippe
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
|
|
From: Josef W. <Jos...@gm...> - 2011-05-30 13:04:37
|
Hi,
this really sounds like a discussion on the color of the bike shed.
Anyway...
On Saturday 28 May 2011, WAROQUIERS Philippe wrote:
> >> Is there a need for vgdb to stick with 2 letters? I much would prefer "clg"
> >> instead. Since years I use the alias clg='valgrind --tool=callgrind', and in
> >> the callgrind sources I use the CLG_ prefix quite often.
> >>
> >
> >I agree with Josef it would be best if we could drop the
> >2-letter-acronym requirement.
While not important in this context, these 2-letter-acronyms are
used a lot in the source, e.g. used in
cachegrind/cg_main.c
MC_(clo_mc_level)
VG_IS_TOOL_USERREQ('M','C',arg[0])
But the only place where they get user-visible is with
cg_{merge,diff,annotate}
and now with the vgdb commands.
> >My preference would be to use the tool
> >name instead (and not some form of abbreviation). That increases
> >usability as it eliminates all confusion. I fail to see the value of
> >having to use an abbreviated tool name in certain contexts. It's just
> >one more thing to remember. And it's not clear to me what the value is
> >in return.
Of course faster typing. Does not matter in a shell with autocompletion,
but for vgdb/gdb promt (?). On the other hand, we do not support
valgrind --tool=cg ...
> The 2 letters is just a convention, we can use more letters.
>
> The only "requirement" are:
> * it should be non-ambiguous, i.e. it is better to have
> a command for a certain tool to not be confused with a command
> from another tool or with a standard core valgrind command.
> So, the idea was that standard core commands are starting
> with vg. while tool commands starts with their own unique
> prefix (e.g. mc. ms. and the to be chosen for callgrind).
I see.
Hmm... vgdb only relays to one tool instance. While I see that
having a separate namespace for core commands can be useful, we
do not really do something like that for command line options, too
(I see some exceptions: --vgdb-poll, but also --cachegrind-out-file).
> The main reason to have short prefix is that that such commands
> are typed often, and the prefix must be typed in full.
Do we really need that prefix?
Comparing with "--help", which outputs command line help for both
valgrind core and the tool, it even could make sense to support
"monitor set ..." for both valgrind core and tool settings without
using a prefix.
> So, for callgrind, we can use clg. as suggested by Josef
> or use cl or ...
Having to remember that "cg" was cachegrind and "clg" was callgrind
is a further burden to the user, and easily gets confusing.
If we can avoid that issue, we should do it. On the command line,
there is no way: valgrind commands compete with all other commands on the
system, and using "<tool>_foo" really seems better than
"<2-letter-acronym of tool>_foo".
But for vgdb commands, I now do not really see a need for the prefix.
As we have our own namespace, we can simply avoid conflicts without a prefix.
And for that matter, "vgdb d" is even faster to type than "vgdb ct.d".
I also find it more natural to say "gdb set instrumentation off" for the
according callgrind_control command.
> I would not like long commands (and/or long arguments that are
> ambiguous unless you type many of the leading characters).
Me too.
Josef
> But if I am in the very few that likes short things to type, I can
> survive with long prefixes and start typing
> list-files-in-directories --output-long-format-with-dates :).
> (of course, I like a lot the gnu convention to have both short and
> long option names, but that looks an overkill for gdbsrv in valgrind).
>
> Philippe
>
>
> ____
>
> This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
>
> Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
>
> Any views expressed in this message are those of the sender.
>
>
|
|
From: WAROQUIERS P. <phi...@eu...> - 2011-05-31 15:27:29
|
>Hmm... vgdb only relays to one tool instance. While I see that >having a separate namespace for core commands can be useful, we >do not really do something like that for command line options, too So, the idea for the monitor commands then would be: Valgrind core commands will have a prefix v. Tool commands will have no prefix. This gives: * no collision between core commands and tool commands * fast to type * no need for tool prefix I will prepare a patch based on the above, so that e.g. Josef can experiment with this, and if feedback is positive, we will have decided about the colour of the bike shed by not painting it :). In the meantime, if someone already sees a problem with the above approach, it is still time to shout. Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Nicholas N. <n.n...@gm...> - 2011-06-01 05:09:33
|
On Mon, May 30, 2011 at 11:04 PM, Josef Weidendorfer <Jos...@gm...> wrote: > > this really sounds like a discussion on the color of the bike shed. I want to keep short prefixes. 2 or 3 letters is fine; DRD uses 'drd' in a lot of places. I want to keep "cg" for Cachegrind, so "clg" for Callgrind is fine; "cl" would be fine too, probably better in fact. I don't want to change anything else. Nick |
|
From: Julian S. <js...@ac...> - 2011-06-01 10:54:24
|
On Wednesday, June 01, 2011, Nicholas Nethercote wrote: > On Mon, May 30, 2011 at 11:04 PM, Josef Weidendorfer > > <Jos...@gm...> wrote: > > this really sounds like a discussion on the color of the bike shed. I agree. > I want to keep short prefixes. 2 or 3 letters is fine; DRD uses > 'drd' in a lot of places. I want to keep "cg" for Cachegrind, so > "clg" for Callgrind is fine; "cl" would be fine too, probably better > in fact. I don't want to change anything else. I agree with that too. I find the short prefixes useful, except we should use "cl" for callgrind instead of "ct". That said, we can't make any changes to the client request numbering because that's a public API which we've more or less promised not to change. J |
|
From: Josef W. <Jos...@gm...> - 2011-06-01 13:30:02
|
On Wednesday 01 June 2011, Julian Seward wrote:
> > I want to keep short prefixes. 2 or 3 letters is fine; DRD uses
> > 'drd' in a lot of places. I want to keep "cg" for Cachegrind, so
> > "clg" for Callgrind is fine; "cl" would be fine too, probably better
> > in fact. I don't want to change anything else.
>
> I agree with that too. I find the short prefixes useful, except we
> should use "cl" for callgrind instead of "ct".
Fine.
Now, this is only about an added alias for "callgrind_{annotate,control}".
For vgdb commands, getting rid of the prefixes (for tools) is much better.
> That said, we can't
> make any changes to the client request numbering because that's a
> public API which we've more or less promised not to change.
Sure. But this isn't really user-visible.
Josef
>
> J
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|