You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(11) |
2
(9) |
3
(11) |
4
(12) |
5
(11) |
|
6
(9) |
7
(13) |
8
(6) |
9
(7) |
10
(7) |
11
(11) |
12
(13) |
|
13
(7) |
14
(6) |
15
(7) |
16
(19) |
17
(20) |
18
(9) |
19
(9) |
|
20
(6) |
21
(7) |
22
(11) |
23
(16) |
24
(14) |
25
(24) |
26
(16) |
|
27
(20) |
28
(58) |
29
(7) |
30
(10) |
31
(15) |
|
|
|
From: Bryan M. <om...@br...> - 2006-08-07 21:47:03
|
Hi Josef,
we should consider irc or skype to chat I think, apart from the lack of
record :(
Bryan
Josef Weidendorfer wrote:
> On Monday 07 August 2006 22:21, you wrote:
>> I was thinking of two cases here: source files that are compiled but not
>> linked and source files that aren't even compiled. Being able to flag
>> these files (large projects can often end up with this sort of "fluff"
>> lying around) would assist further in cleanup / test development.
>
> I am not sure, that "not even compiled files" should influence the coverage.
> How do you want to detect them? Of course, debug info is not available for
> such files, and you would need to parse them yourself.
We would already have a list of source files in a directory. Flagging up
source files not in the list should be trivial. A separate "source file
with no executable lines" statistic or something as simple would do the
job. I just intended for it to draw attention to there being a source
file that isn't being used - the ultimate in 0 coverage...
>
>>> With "lineWithCode", the problem to show huge context should be gone.
>> A "show entire file" option might be a nice alternative?
>
> Hmm... yeah, I could put this option into the context menu for
> source annotation. The same for assembler annotation (show disassembler
> of full object) is probably not such a good idea...
indeed.
>
>>>> The "ignores some files" thing is because I can only have 499 items in a
>>>> list box.
>>> ??
>>> Sorry, where does this limitation come from? Are you talking about
>>> Covergrind or KCachegrind?
>> KCachegrind: the list box in the bottom left shows something along the
>> lines of "ignoring X files < Y". By increasing the list box size in the
>> options dialog up to 499 on my small test run, this problem goes away.
>> The 500 limit is way to small for some of the stuff I intend to run this on.
>
> Ah, I see. The 500 was a pure arbitrary limit, to keep the GUI snappy;
> some limit is needed because Qt3 creates for every list item an object,
> so huge lists are both time/space consuming (and running OpenOffice, you
> easily get 50000 functions). This will be moot with Qt4, as list items
> use the applications own model there, so huge lists do not add any
> overhead. However, with profiling, you usually are only interested in the
> top entries.
I thought it would be something like this (I have inexpertly used QT
before). For profiling, this is fine but for coverage, every file is
interesting and should be available.
>
>>>> This is going to be a major headache at work where the file
>>>> count is well above 1000 (and probably at least 2000).
>>> Hmm, shouldn't be a problem.
>> It should handle the files, I just wont be able to select them all
>> because the list box wont display more than 499.
>
> Yup.
>
>> If it is doing a binary search, (without looking at the code) it might
>> be possible to adapt it / generate another function to walk part of the
>> list / tree, calling a passed in function pointer or some such. I will
>> have a look at this as simple access to the results of the parsing
>> output but in a linear format based on source lines would be really
>> useful. I will see what I can do and post some patches
>
> Sure, some useful extension of the tool API is always welcome.
>
storage.c looks as though it would be the place for a new function.
Passing in a filename and returning the source line data shouldn't be
too difficult by the look of it.
>> The new functionality could possibly even return something like:
>>
>> struct lines {
>> int size;
>> char *bits;
>> }
>>
>> where size is the amount of memory malloced onto bits and bits are set
>> based upon line number:
>>
>> bits[line_num / (sizeof(char) * 8)] |=
>> (1 << (line_num & (((sizeof(char) * 8) - 1)));
>
> Hmm, this looks already quite complicated. Why not an iterator function?
It looks a lot simpler with the sizeof(char) stripped out (assuming it
to be 1 can be dangerous sometimes):
bits[line_num / 8] |= (1 << (line_num & 7));
At some point, the information would probably need to be stored. I
remember reading that the debug information is lost when an object is
unloaded. If this is the case (I'm old - my memory can be a right thingy
at times) then the read would have to happen mid run and the information
be cached until the end when it can be output. This is unless the file
format for kcachegrind is happy to have intermingled files and function
information in which case, it could be output immediately and an
iterator might be fast enough. The key thing for me is to minimise the
impact to the program under test thus allowing a greater range of
programs to use it.
>
> Josef
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Josef W. <Jos...@gm...> - 2006-08-07 21:08:14
|
On Monday 07 August 2006 22:21, you wrote:
> I was thinking of two cases here: source files that are compiled but not
> linked and source files that aren't even compiled. Being able to flag
> these files (large projects can often end up with this sort of "fluff"
> lying around) would assist further in cleanup / test development.
I am not sure, that "not even compiled files" should influence the coverage.
How do you want to detect them? Of course, debug info is not available for
such files, and you would need to parse them yourself.
> > With "lineWithCode", the problem to show huge context should be gone.
>
> A "show entire file" option might be a nice alternative?
Hmm... yeah, I could put this option into the context menu for
source annotation. The same for assembler annotation (show disassembler
of full object) is probably not such a good idea...
>
> >
> >> The "ignores some files" thing is because I can only have 499 items in a
> >> list box.
> >
> > ??
> > Sorry, where does this limitation come from? Are you talking about
> > Covergrind or KCachegrind?
>
> KCachegrind: the list box in the bottom left shows something along the
> lines of "ignoring X files < Y". By increasing the list box size in the
> options dialog up to 499 on my small test run, this problem goes away.
> The 500 limit is way to small for some of the stuff I intend to run this on.
Ah, I see. The 500 was a pure arbitrary limit, to keep the GUI snappy;
some limit is needed because Qt3 creates for every list item an object,
so huge lists are both time/space consuming (and running OpenOffice, you
easily get 50000 functions). This will be moot with Qt4, as list items
use the applications own model there, so huge lists do not add any
overhead. However, with profiling, you usually are only interested in the
top entries.
> >> This is going to be a major headache at work where the file
> >> count is well above 1000 (and probably at least 2000).
> >
> > Hmm, shouldn't be a problem.
>
> It should handle the files, I just wont be able to select them all
> because the list box wont display more than 499.
Yup.
> If it is doing a binary search, (without looking at the code) it might
> be possible to adapt it / generate another function to walk part of the
> list / tree, calling a passed in function pointer or some such. I will
> have a look at this as simple access to the results of the parsing
> output but in a linear format based on source lines would be really
> useful. I will see what I can do and post some patches
Sure, some useful extension of the tool API is always welcome.
> The new functionality could possibly even return something like:
>
> struct lines {
> int size;
> char *bits;
> }
>
> where size is the amount of memory malloced onto bits and bits are set
> based upon line number:
>
> bits[line_num / (sizeof(char) * 8)] |=
> (1 << (line_num & (((sizeof(char) * 8) - 1)));
Hmm, this looks already quite complicated. Why not an iterator function?
Josef
|
|
From: Bryan M. <om...@br...> - 2006-08-07 20:21:41
|
Josef,
more comments below.
Bryan
Josef Weidendorfer wrote:
> On Monday 07 August 2006 01:32, Bryan Meredith wrote:
>> One thing of note - I set the context in kcachegrind to be 50 so that in
>> effect, the whole of the file is displayed. The display goes past the
>> end of the file.
>
> Oops :-)
>
>> I shall download the latest source (really not sure
>> what version I am running) and see if I can put a patch together for you
>> to consider. There is also the issue of showing source files that don't
>> get hit at all - maybe there is some scan that could be run from a menu
>> option for that? I don't know. I will look at this as well.
>
> I really would suggest to generate a file with the event "lineWithCode"
> (either within a Covergrind run, or offline), and load this into KCachegrind
> with the original data. Currently, you have to use "File/Add" to merge
> data files within KCachegrind (or use a special naming, like Callgrind is
> doing for parts of one profile run).
I was thinking of two cases here: source files that are compiled but not
linked and source files that aren't even compiled. Being able to flag
these files (large projects can often end up with this sort of "fluff"
lying around) would assist further in cleanup / test development.
>
> Unfortunately, this merging will always default to add event counts, which
> is wrong for coverage: If in run 1, function foo has 20 lines touched, and
> in run 2, there are 15 lines touched, the merge will show 35 lines touched.
> It would be better for merging to specify other reductions for events types
> like min/max etc.
>
> With "lineWithCode", the problem to show huge context should be gone.
A "show entire file" option might be a nice alternative?
>
>> The "ignores some files" thing is because I can only have 499 items in a
>> list box.
>
> ??
> Sorry, where does this limitation come from? Are you talking about
> Covergrind or KCachegrind?
KCachegrind: the list box in the bottom left shows something along the
lines of "ignoring X files < Y". By increasing the list box size in the
options dialog up to 499 on my small test run, this problem goes away.
The 500 limit is way to small for some of the stuff I intend to run this on.
>
>> This is going to be a major headache at work where the file
>> count is well above 1000 (and probably at least 2000).
>
> Hmm, shouldn't be a problem.
It should handle the files, I just wont be able to select them all
because the list box wont display more than 499.
>
>> I shall have another read through the source for the debug information
>> parsing. I don't want to do anything whilst the program is running
>
> Getting this debug information once for an ELF object should be neglectable
> in a Valgrind run. If you are doing multiple runs (regression tests) in a row
> on the same binary, you could add a command line option to do it only once.
>
> However, the current Valgrind Tool API for debug information can not
> simply iterate over info in a given address range, but you have to
> request debug info for every address, which will interally do a
> binary search again and again. Still, it should work reasonable fast.
If it is doing a binary search, (without looking at the code) it might
be possible to adapt it / generate another function to walk part of the
list / tree, calling a passed in function pointer or some such. I will
have a look at this as simple access to the results of the parsing
output but in a linear format based on source lines would be really
useful. I will see what I can do and post some patches for people to
laugh at :D
The new functionality could possibly even return something like:
struct lines {
int size;
char *bits;
}
where size is the amount of memory malloced onto bits and bits are set
based upon line number:
bits[line_num / (sizeof(char) * 8)] |=
(1 << (line_num & (((sizeof(char) * 8) - 1)));
For the processing overhead, you end up with a pretty compact
representation of the lines with code on them. Maybe this could be
cached and a pointer to it be returned instead? Anyway, I will have a
look at the code and see what presents itself (and if anyone else gets
there first, feel free to jump in!).
>
> Josef
>
> PS: It would be perfect if KCachegrind generally would get more useful
> for diverse tasks.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Bryan M. <om...@br...> - 2006-08-07 19:59:17
|
Patrick, thanks for the input. If the compiled object is available, there should be nothing to stop some "offline" analysis to determine the executable lines within it. It would be better if all of this could automagically be done by a GUI or some other pre/post processing tool rather than as a set of manual steps, but done this way, ALL of the relevant information would be available to perform whatever analysis you wish. The other advantage is that this wouldn't impact the size or speed of the executable under test and you could also cull this information from the "other" ;) OS if you really wanted to do the comparison. Bryan "Brain Murders" Meredith Patrick Ohly wrote: > On Sat, 2006-08-05 at 12:52 +0100, Bryan Meredith wrote: >>> Also, does it give percentage coverage? >> Again, in the GUI, with both the source file and line coverage >> information available, it will be simpler to generate any required >> metrics (another long way of saying No). > > Actually this might be the right approach to handle a problem that no > other coverage tool that I am aware of handles right: if you link the > same object code, say from a static library, into different executables > and then run those multiple times, then merging coverage information > about the original object code can be very hard. Now assuming that the > same source code is compiled differently into different object files > (think Linux and Windows, with and without debugging enabled, etc.) and > then executed the object file based approach completely fails - > basically you have to merge information about the source code in this > case, as you suggest. > > The drawback (and I suppose that was what Nicholas was pointing out) is > then that you don't have information about number of code lines compiled > into the object files or executables, so you have to fall back to less > reliable methods of source code analysis to have a baseline for the > percentage of covered lines of code. > |
|
From: Patrick O. <pat...@in...> - 2006-08-07 14:48:32
|
On Sat, 2006-08-05 at 12:52 +0100, Bryan Meredith wrote: > > Also, does it give percentage coverage? > > Again, in the GUI, with both the source file and line coverage > information available, it will be simpler to generate any required > metrics (another long way of saying No). Actually this might be the right approach to handle a problem that no other coverage tool that I am aware of handles right: if you link the same object code, say from a static library, into different executables and then run those multiple times, then merging coverage information about the original object code can be very hard. Now assuming that the same source code is compiled differently into different object files (think Linux and Windows, with and without debugging enabled, etc.) and then executed the object file based approach completely fails - basically you have to merge information about the source code in this case, as you suggest. The drawback (and I suppose that was what Nicholas was pointing out) is then that you don't have information about number of code lines compiled into the object files or executables, so you have to fall back to less reliable methods of source code analysis to have a baseline for the percentage of covered lines of code. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Julian S. <js...@ac...> - 2006-08-07 12:10:59
|
Darn. I feared that might happen. How can we avoid building insn_sse3 on platforms with assemblers too old to understand such insns? J On Monday 07 August 2006 03:24, Tom Hughes wrote: > Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-07 03:15:02 > BST Results differ from 24 hours ago > > Checking out valgrind source tree ... done > Configuring valgrind ... done > Building valgrind ... done > Running regression tests ... failed > > Last 20 lines of verbose log follow echo > /tmp/ccrKSTrh.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccrKSTrh.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' > make[5]: *** [insn_sse3.o] Error 1 > rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c > insn_cmov.c insn_basic.c make[5]: Leaving directory > `/tmp/valgrind.4934/valgrind/none/tests/x86' make[4]: *** [check-am] Error > 2 > make[4]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests/x86' > make[3]: *** [check-recursive] Error 1 > make[3]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests' > make[2]: *** [check-recursive] Error 1 > make[2]: Leaving directory `/tmp/valgrind.4934/valgrind/none' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory `/tmp/valgrind.4934/valgrind' > make: *** [check] Error 2 > ================================================= > == Results from 24 hours ago == > ================================================= > > Checking out valgrind source tree ... done > Configuring valgrind ... done > Building valgrind ... done > Running regression tests ... failed > > Last 20 lines of verbose log follow echo > /tmp/ccEGJmN7.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' > /tmp/ccEGJmN7.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' > make[5]: *** [insn_sse3.o] Error 1 > rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c > insn_cmov.c insn_basic.c make[5]: Leaving directory > `/tmp/valgrind.4934/valgrind/none/tests/x86' make[4]: *** [check-am] Error > 2 > make[4]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests/x86' > make[3]: *** [check-recursive] Error 1 > make[3]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests' > make[2]: *** [check-recursive] Error 1 > make[2]: Leaving directory `/tmp/valgrind.4934/valgrind/none' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory `/tmp/valgrind.4934/valgrind' > make: *** [check] Error 2 > > ================================================= > == Difference between 24 hours ago and now == > ================================================= > > *** old.short Mon Aug 7 03:19:34 2006 > --- new.short Mon Aug 7 03:24:12 2006 > *************** > *** 7,16 **** > Last 20 lines of verbose log follow echo > ! /tmp/ccEGJmN7.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccEGJmN7.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' > make[5]: *** [insn_sse3.o] Error 1 > --- 7,16 ---- > Last 20 lines of verbose log follow echo > ! /tmp/ccrKSTrh.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' > ! /tmp/ccrKSTrh.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' > make[5]: *** [insn_sse3.o] Error 1 > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys -- and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <js...@ac...> - 2006-08-07 09:13:06
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-07 09:00:01 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 206 tests, 10 stderr failures, 5 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Tom H. <th...@cy...> - 2006-08-07 06:22:26
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-07 03:00:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 262 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) |
|
From: <js...@ac...> - 2006-08-07 03:04:02
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-07 03:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 235 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) |
|
From: Tom H. <to...@co...> - 2006-08-07 02:46:16
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-07 03:30:09 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-08-07 02:25:34
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-07 03:10:10 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 260 tests, 3 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-08-07 02:24:20
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-07 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccrKSTrh.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccrKSTrh.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.4934/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.4934/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccEGJmN7.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccEGJmN7.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.4934/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.4934/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.4934/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Aug 7 03:19:34 2006 --- new.short Mon Aug 7 03:24:12 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccEGJmN7.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccEGJmN7.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccrKSTrh.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccrKSTrh.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Josef W. <Jos...@gm...> - 2006-08-07 00:32:47
|
On Monday 07 August 2006 01:32, Bryan Meredith wrote: > One thing of note - I set the context in kcachegrind to be 50 so that in > effect, the whole of the file is displayed. The display goes past the > end of the file. Oops :-) > I shall download the latest source (really not sure > what version I am running) and see if I can put a patch together for you > to consider. There is also the issue of showing source files that don't > get hit at all - maybe there is some scan that could be run from a menu > option for that? I don't know. I will look at this as well. I really would suggest to generate a file with the event "lineWithCode" (either within a Covergrind run, or offline), and load this into KCachegrind with the original data. Currently, you have to use "File/Add" to merge data files within KCachegrind (or use a special naming, like Callgrind is doing for parts of one profile run). Unfortunately, this merging will always default to add event counts, which is wrong for coverage: If in run 1, function foo has 20 lines touched, and in run 2, there are 15 lines touched, the merge will show 35 lines touched. It would be better for merging to specify other reductions for events types like min/max etc. With "lineWithCode", the problem to show huge context should be gone. > The "ignores some files" thing is because I can only have 499 items in a > list box. ?? Sorry, where does this limitation come from? Are you talking about Covergrind or KCachegrind? > This is going to be a major headache at work where the file > count is well above 1000 (and probably at least 2000). Hmm, shouldn't be a problem. > I shall have another read through the source for the debug information > parsing. I don't want to do anything whilst the program is running Getting this debug information once for an ELF object should be neglectable in a Valgrind run. If you are doing multiple runs (regression tests) in a row on the same binary, you could add a command line option to do it only once. However, the current Valgrind Tool API for debug information can not simply iterate over info in a given address range, but you have to request debug info for every address, which will interally do a binary search again and again. Still, it should work reasonable fast. Josef PS: It would be perfect if KCachegrind generally would get more useful for diverse tasks. |