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
(17) |
2
(21) |
3
(17) |
4
(28) |
5
(21) |
6
(11) |
|
7
(13) |
8
(21) |
9
(21) |
10
(9) |
11
(11) |
12
(15) |
13
(23) |
|
14
(15) |
15
(22) |
16
(28) |
17
(12) |
18
(15) |
19
(8) |
20
(7) |
|
21
(8) |
22
(12) |
23
(13) |
24
(7) |
25
(7) |
26
(3) |
27
(9) |
|
28
(13) |
29
(7) |
30
(7) |
31
(9) |
|
|
|
|
From: Doug R. <df...@nl...> - 2004-03-05 20:26:35
|
On Friday 05 March 2004 18:28, Jeremy Fitzhardinge wrote:
> On Fri, 2004-03-05 at 06:28, Doug Rabson wrote:
> > I've definately fixed this one - this is debug information for the
> > C++ 'member function pointer' type.
>
> Actually I think it's just pointer to member, not member function.
> Anyway, I checked in a fix last night, which probably looks a lot
> like yours.
>
> What are your other changes to vg_stabs/vg_symtab2?
I have three main changes in the stabs parser:
Templates which look like, e.g. "typedef MacFileName : public
FileName<':'>" confuse the type parser. It sees the colon and thinks
its at the end of the type. The fix was to keep track of quotes.
Some output from old binutils (mainly 2.11.2 which appears in FreeBSD
4.6.2) seems to have bogus address values for some N_FUN entries which
confuses things. I detect the broken N_FUN entries and look up the
symbol value manually.
When parsing the N_SOL stabs fields (debug record for start of include
file), queue the N_SOL filename until after emitting the already
pending N_SLINE so that we can get the right value for the end of the
N_SLINE. This improves the line number accuracy in some cases.
There are two changes to vg_symtab2.c. The first ignores negative size
scope entries (which also seem to appear with buggy old binutils). The
second tries to be smarter when two line ranges overlap by taking the
larger region, not just the last one. This helps to ensure that there
are no holes in the line number coverage.
Patch below:
Index: vg_stabs.c
===================================================================
--- vg_stabs.c (.../trunk/coregrind/vg_stabs.c) (revision 305)
+++ vg_stabs.c (.../branches/dfr-merge/coregrind/vg_stabs.c) (revision
305)
@@ -669,20 +669,25 @@
case 'x': { /* reference to undefined type */
/* 'x' ('s' | 'u' | 'e') NAME ':' */
Int brac = 0; /* < > brackets in type */
+ Bool quote = False; /* ' ' string in type */
Char kind = *p++; /* get kind */
Char *name = p;
/* name is delimited by : except for :: within <> */
for(;;) {
- if (*p == '<')
- brac++;
- if (*p == '>')
- brac--;
- if (*p == ':') {
- if (brac && p[1] == ':')
- p += 1;
- else
- break;
+ if (*p == '\'')
+ quote = !quote;
+ if (!quote) {
+ if (*p == '<')
+ brac++;
+ if (*p == '>')
+ brac--;
+ if (*p == ':') {
+ if (brac && p[1] == ':')
+ p += 1;
+ else
+ break;
+ }
}
p++;
}
@@ -1160,8 +1165,9 @@
} func = { 0, 0, NULL, NULL, -1 };
struct {
Char *name;
+ Char *next;
Bool same;
- } file = { NULL, True };
+ } file = { NULL, NULL, True };
struct {
Int prev; /* prev line */
Int no; /* current line */
@@ -1336,13 +1342,23 @@
break;
case N_SOL: /* sub-source (include) file */
+ {
+ UChar *nm = string;
+ UInt len = VG_(strlen)(nm);
if (line.ovf != 0)
VG_(message)(Vg_UserMsg,
"Warning: file %s is very big (> 65535
lines) "
"Line numbers and annotation for this file
might "
"be wrong. Sorry",
file.name);
- /* FALLTHROUGH */
+ if (len > 0 && nm[len-1] != '/') {
+ file.next = VG_(addStr)(si, nm, -1);
+ if (debug)
+ VG_(printf)("new source: %s\n", file.name);
+ } else if (len == 0)
+ file.next = VG_(addStr)(si, "?1\0", -1);
+ }
+ break;
case N_SO: { /* new source file */
UChar *nm = string;
@@ -1353,6 +1369,10 @@
/* finish off previous line */
VG_(addLineInfo)(si, file.name, line.addr,
addr, line.no + line.ovf * LINENO_OVERFLOW, i);
+ if(file.next) {
+ file.name = file.next;
+ file.next = (Char *)0;
+ }
}
/* reset line state */
@@ -1385,6 +1405,10 @@
/* there was a previous */
VG_(addLineInfo)(si, file.name, line.addr,
addr, line.no + line.ovf * LINENO_OVERFLOW, i);
+ if(file.next) {
+ file.name = file.next;
+ file.next = (Char *)0;
+ }
}
line.addr = addr;
@@ -1446,7 +1470,10 @@
line.first = False;
/* end line at end of function */
- addr = func.start + st->n_value;
+ if (st->n_value > 0)
+ addr = func.start + st->n_value;
+ else
+ addr = line.addr;
if (debug)
VG_(printf)("ending func %s at %p\n", func.name, addr);
@@ -1455,6 +1482,15 @@
func.name = no_fn_name;
func.start = 0;
+ if (line.addr) {
+ VG_(addLineInfo)(si, file.name, line.addr,
+ addr, line.no + line.ovf * LINENO_OVERFLOW, i);
+ if(file.next) {
+ file.name = file.next;
+ file.next = (Char *)0;
+ }
+ line.addr = 0;
+ }
if (scope.addr != 0) {
/* finish any previous scope range */
VG_(addScopeInfo)(si, scope.addr, addr, scope.scope);
@@ -1481,7 +1517,26 @@
line.first = True;
/* line ends at start of next function */
- addr = si->offset + st->n_value;
+ if (st->n_value == 0) {
+ UInt j;
+ Char *name, *p;
+ p = VG_(strchr)(string, ':');
+ name = VG_(arena_malloc)(VG_AR_SYMTAB, p - string + 1);
+ memcpy(name, string, p - string);
+ name[p - string] = 0;
+ addr = 0;
+ for (j = 0; j < si->symtab_used; j++) {
+ if (0)
+ VG_(printf)("%p %s\n", si->symtab[j].addr, si->symtab[j].name);
+ if (0 == VG_(strcmp)(name, si->symtab[j].name)) {
+ addr = si->symtab[j].addr;
+ break;
+ }
+ }
+ VG_(arena_free)(VG_AR_SYMTAB, name);
+ } else {
+ addr = si->offset + st->n_value;
+ }
func.start = addr;
func.name = string;
@@ -1494,6 +1549,10 @@
if (line.addr) {
VG_(addLineInfo)(si, file.name, line.addr,
addr, line.no + line.ovf * LINENO_OVERFLOW, i);
+ if(file.next) {
+ file.name = file.next;
+ file.next = (Char *)0;
+ }
line.addr = 0;
}
Index: vg_symtab2.c
===================================================================
--- vg_symtab2.c (.../trunk/coregrind/vg_symtab2.c) (revision 305)
+++ vg_symtab2.c (.../branches/dfr-merge/coregrind/vg_symtab2.c)
(revision 305)
@@ -308,6 +308,13 @@
return;
}
+ /* Ignore negative-sized scopes */
+ if (this > next) {
+ if (debug)
+ VG_(printf)("ignoring negative-sized range, scope %p at %p\n", scope,
this);
+ return;
+ }
+
if (debug)
VG_(printf)("adding scope range %p-%p (size=%d) scope %p
(%d)\n",
this, next, next-this, scope, scope->depth);
@@ -668,6 +675,10 @@
/* If two adjacent entries overlap, truncate the first. */
for (i = 0; i < ((Int)si->loctab_used)-1; i++) {
vg_assert(si->loctab[i].size < 10000);
+ if(si->loctab[i].addr == si->loctab[i+1].addr
+ && si->loctab[i].size > si->loctab[i+1].size) {
+ SWAP(RiLoc,si->loctab[i],si->loctab[i+1]);
+ }
if (si->loctab[i].addr + si->loctab[i].size >
si->loctab[i+1].addr) {
/* Do this in signed int32 because the actual .size fields
are unsigned 16s. */
--
Doug Rabson Mail: df...@nl...
Phone: +44 20 8340 9918
|
|
From: KJK::Hyperion <no...@li...> - 2004-03-05 20:18:24
|
At 01.14 02/03/2004, Jeremy Fitzhardinge wrote:
>Well, the thing which Valgrind ideally wants is two complete address
>spaces: one for the client, and one for Valgrind.
are you 100% sure of what you're saying? if I understand correctly, at
least the JIT compiler needs to run in the same process as the client.
Otherwise we'd have an insane amount of inter-process memory copying, which
doesn't exactly come for free
>The idea is that the Valgrind should be able to control all the activity
>in the client address space, control execution, inject generated code,
>etc. We can't get that with the Unix memory model, but maybe we can use
>the (otherwise very painful) cross-address space features of Windows to
>get this effect.
this sounds like good news, finally. Is there an updated technical
overview? last time I looked, it said Valgrind didn't do multithreading
>Does this mean that if we translate this code into the instrumented code
>cache, then things will care because the EIP isn't within the
>kernel/user/gdi.dll?
no, this shouldn't be a problem, it only hurt full virtualization. The
kernel-mode windowing and graphics code does call back to user-mode, but it
only does so through a well-defined entry point - one of the entry points
Valgrind will have to catch anyway not to lose control
Apropos, some details for the other Windows guys:
- the entry points (exported by ntdll.dll) are:
- KiRaiseUserExceptionDispatcher
- KiUserApcDispatcher
- KiUserCallbackDispatcher
- KiUserExceptionDispatcher
KiUserApcDispatcher will always be hit at least once per thread, as an
APC is queued to all threads to run the initialization code. We won't need
to do special handling of any of them, though. We'll just switch to the JIT
upon entering one of them. The first thread entering the JIT will
initialize it, the others will spin until initialization is done. We could
detect new threads by checking the flat address of their TEB against an
internal table, or by allocating a TLS slot and checking for its value
(NULL -> new thread)
- the entry points above aren't enough. Some control transfers happen
outside of them - luckily there aren't many. I've counted three:
ZwContinue, ZwSetContextThread and ZwVdmControl. The first two are easy,
the third is a mistery. I know it causes control transfers to and from V86
virtual machines, but how does it do that is not known - luckily, only
NTVDM uses it
- catching system calls is a mess. Hooking system calls directly in
kernel mode, as dangerous as it is, is the best way for several reasons. I
don't like how that strace for Windows does it, though. To signal a call
I'd raise an exception: it's semantically correct, so it will work well
with existing (and future) code
>Also, is this code running in Ring 3, or a privileged level?
in normal processes, all code runs at ring 3. Well, winsrv.dll (in the
CSRSS process) has a couple of functions (in user-mode memory) that run in
kernel-mode, in kernel-mode threads created by win32k.sys, but it's the
only instance I know of. Well, the PsCreateSystemThread function *is*
documented in the driver writing documentation, and it *could* be used to
create kernel-mode threads in any process, but I'd be surprised if anyone
used it on a process that isn't System. And even in that case it isn't
something Valgrind can possibly control, and it won't be commonplace
|
|
From: Doug R. <df...@nl...> - 2004-03-05 18:48:58
|
On Fri, 2004-03-05 at 18:28, Jeremy Fitzhardinge wrote: > On Fri, 2004-03-05 at 06:28, Doug Rabson wrote: > > I've definately fixed this one - this is debug information for the C++ > > 'member function pointer' type. > > Actually I think it's just pointer to member, not member function. > Anyway, I checked in a fix last night, which probably looks a lot like > yours. The diff certainly looked like what I did. > > What are your other changes to vg_stabs/vg_symtab2? I'll merge with your change and work up a set of diffs for you (with explanation). |
|
From: Jeremy F. <je...@go...> - 2004-03-05 18:35:36
|
On Fri, 2004-03-05 at 06:28, Doug Rabson wrote: > I've definately fixed this one - this is debug information for the C++ > 'member function pointer' type. Actually I think it's just pointer to member, not member function. Anyway, I checked in a fix last night, which probably looks a lot like yours. What are your other changes to vg_stabs/vg_symtab2? J |
|
From: Doug R. <df...@nl...> - 2004-03-05 14:35:38
|
On Thu, 2004-03-04 at 23:52, George Staikos wrote:
> On Thursday 04 March 2004 18:13, George Staikos wrote:
> > > - /* Ignore zero-sized scopes */
> > > - if (this == next) {
> > > + /* Ignore zero-sized or negative scopes */
> > > + if (size <= 0) {
> >
> > This is exactly the first thing I tried, and then I got more errors after
> > that, so I assumed it was more complex. I'm going to try the latest
> > snapshot of PPC valgrind and if this fix is not included, I'll add it in
> > again. However the log looked worse last time. :-) I'll post the new
> > results when I get them.
>
> As a followup, with the latest PPC patch and this patch applied, things work
> better, but are still quite broken. The simple 'cout << "Hello world"' app
> now works fine (no errors reported), but with the Qt examples/hello demo I
> get 30000:
> ==26698== Conditional jump or move depends on uninitialised value(s)
>
> At startup I also see:
>
> @@ expected ';' at type attrib (ptr="(99,1),(8,12)")
> @@ unlikely looking definition in unparsed remains "(0,219)=@(99,1),(8,12)"
>
> I saw this yesterday when I tried the size <= 0 patch too.
I've definately fixed this one - this is debug information for the C++
'member function pointer' type.
|
|
From: Doug R. <df...@nl...> - 2004-03-05 14:34:15
|
On Thu, 2004-03-04 at 20:13, George Staikos wrote: > I was trying out valgrind on powerpc recently and while it works fine with > C applications, C++ apps seem to be giving it some serious problems. I > compiled helloworld.cpp, basically just 'cout << "Hello world." << endl;', > and when I run it through valgrind I get this assertion failure: I think I've fixed this one in my FreeBSD valgrind. I have some testers who are using some really old copies of binutils which emit dodgy stabs debugging information. You might be able to just drop in copies of vg_stabs.c and vg_symtab2.c from svn://svn.rabson.org/repos/valgrind/branches/dfr/coregrind. |
|
From: <sun...@te...> - 2004-03-05 13:55:46
|
Hi,
I have the following instrumentation routine:
if (is_entry)
{
funIdx idx;
idx =3D add_function(fnname);
VG_(call_helper_1_0)(cb, (Addr) &function_entry_hook, idx, 0);
}
=20
for (i =3D 0; i < VG_(get_num_instrs)(cb_in); i++) {
u =3D VG_(get_instr)(cb_in, i);
switch (u->opcode) {
case NOP: case LOCK: case CALLM_S: case CALLM_E:
break;
case JMP:
if (u->jmpkind =3D=3D JmpRet)
{
VG_(call_helper_0_0)(cb, (Addr) &function_exit_hook);
}
VG_(copy_UInstr)(cb, u);
break;
=20
default:
VG_(copy_UInstr)(cb, u);
break;
}
=20
}=20
VG_(free_UCodeBlock)(cb_in);
return cb;
Where function_entry/exit_hook are simply increment or decrement counters=
.
I expect that this will give me the number of instrumented functions insi=
de the
stack, but sometimes I get more exits than entrances.
Can anyone explain why this happens?
Thanks,
Yair
|
|
From: Stephan K. <co...@su...> - 2004-03-05 09:02:33
|
On Thursday 04 March 2004 20:55, Josef Weidendorfer wrote: > > Or can you package both stable and unstable versions, e.g. putting CVS version > in a package "valgrind-unstable", using perhaps even different command names Well, I wouldn't mind, but as it stands "valgrind" would be impossible to run on anything but hello world (even /bin/ls links against libpthread these days) > (valgrindunstable), so that one can have installed both versions > simultaneously? > Why is VG 2.0.x not working? I blame NPTL :) A not working calltree is of course something that would make a valgrind CVS a pretty hard decision ;( Greetings, Stephan |
|
From: Nicholas N. <nj...@ca...> - 2004-03-05 08:56:41
|
On Thu, 4 Mar 2004, George Staikos wrote: > FYI: I'm using a much different system than Paul - different glibc, > compiler, and probably kernel. I guess we can expect some differences. Getting Valgrind to work reliably on multiple x86 systems took (and takes) a lot of effort, so these problems aren't surprising. It's just a maturity thing. N |
|
From: Jeremy F. <je...@go...> - 2004-03-05 05:50:25
|
CVS commit by fitzhardinge:
Fix bug 76780 - implement stabs type '@' for pointer to member.
M +41 -23 vg_stabs.c 1.7
--- valgrind/coregrind/vg_stabs.c #1.6:1.7
@@ -301,33 +301,39 @@ static StabType *getStabType(StabTypeTab
}
-static Bool isdigit(Char c, Int base, Int *v)
+static Bool isdigit(Char c, Int base, Int *vp)
{
+ Bool ret = False;
+ Int v = 0;
+
switch(base) {
case 10:
case 0:
- *v = c - '0';
- return c >= '0' && c <= '9';
+ v = c - '0';
+ ret = (c >= '0' && c <= '9');
+ break;
case 8:
- *v = c - '0';
- return c >= '0' && c <= '7';
+ v = c - '0';
+ ret = (c >= '0' && c <= '7');
+ break;
case 16:
if (c >= '0' && c <= '9') {
- *v = c - '0';
- return True;
- }
- if (c >= 'a' && c <= 'f') {
- *v = c - 'a';
- return True;
- }
- if (c >= 'A' && c <= 'F') {
- *v = c - 'F';
- return True;
+ v = c - '0';
+ ret = True;
+ } else if (c >= 'a' && c <= 'f') {
+ v = c - 'a';
+ ret = True;
+ } else if (c >= 'A' && c <= 'F') {
+ v = c - 'F';
+ ret = True;
}
- return False;
+ break;
}
- return False;
+ if (vp && ret)
+ *vp = v;
+
+ return ret;
}
@@ -535,6 +541,9 @@ static SymType *stabtype_parser(SegInfo
VG_(printf)("defining type %p (%d,%d) = %s\n", symtype, file, sym, p);
- /* skip type attributes */
- while(*p == '@')
+ /* Skip type attributes
+ '@' could also be pointer-to-member, so we need to see if
+ the following character looks like a type reference or not.
+ */
+ while(*p == '@' && !(VG_(isdigit)(p[1]) || p[1] == '-' || p[1] == '(') )
p = SKIPPAST(p+1, ';', "type attrib");
@@ -645,5 +654,5 @@ static SymType *stabtype_parser(SegInfo
case '&': /* reference */
case '*': { /* pointer */
- /* '*' TYPE */
+ /* ('*' | '&') TYPE */
type = stabtype_parser(si, NULL, &p);
type = VG_(st_mkpointer)(def, type);
@@ -653,5 +662,5 @@ static SymType *stabtype_parser(SegInfo
case 'k': /* const */
case 'B': { /* volatile */
- /* 'k' TYPE */
+ /* ('k' | 'B') TYPE */
type = stabtype_parser(si, NULL, &p);
break;
@@ -702,5 +711,5 @@ static SymType *stabtype_parser(SegInfo
case 'P': /* packed array */
case 'a': { /* array */
- /* a IDX-TYPE TYPE */
+ /* ( 'a' | 'P' ) IDX-TYPE TYPE */
SymType *idxtype;
SymType *artype;
@@ -733,5 +742,5 @@ static SymType *stabtype_parser(SegInfo
/* Gad. Here we go:
- 's' SIZE
+ ( 's' | 'u' ) SIZE
( '!' NBASE ',' ( VIRT PUB OFF ',' BASE-TYPE ){NBASE} )?
@@ -932,4 +941,13 @@ static SymType *stabtype_parser(SegInfo
break;
+ case '@': /* pointer to member */
+ /* '@' CLASS-TYPE ',' MEMBER-TYPE */
+ type = VG_(st_mkint)(def, sizeof(int), False); /* make it an int for our use */
+
+ stabtype_parser(si, NULL, &p); /* CLASS-TYPE */
+ EXPECT(',', "member-pointer CLASS-TYPE");
+ stabtype_parser(si, NULL, &p); /* MEMBER-TYPE */
+ break;
+
default:
VG_(printf)(" @@ don't know what type '%c' is\n", t);
|
|
From: <js...@ac...> - 2004-03-05 04:13:21
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-03-05 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-03-05 03:56:12
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-03-05 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-03-05 03:29:01
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-05 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 127 tests, 15 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-05 03:24:10
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-05 03:15:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 127 tests, 1 stderr failure, 0 stdout failures ================= helgrind/tests/inherit (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-05 03:19:40
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-05 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 127 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-05 03:16:32
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-05 03:00:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 127 tests, 12 stderr failures, 5 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/pth_cancel2 (stderr) corecheck/tests/pth_cvsimple (stdout) corecheck/tests/pth_cvsimple (stderr) corecheck/tests/pth_exit (stderr) corecheck/tests/res_search (stdout) helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/pth_blockedsig (stdout) none/tests/pth_blockedsig (stderr) none/tests/yield (stdout) none/tests/yield (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-05 03:14:20
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-05 03:05:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 127 tests, 12 stderr failures, 3 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/res_search (stdout) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2004-03-05 01:46:26
|
On Thu, 2004-03-04 at 17:30, George Staikos wrote: > Anything else specifically that I can enable to get more info? The debug > flags in the stabs seem to be capable of enabling rediculous amounts of > information... Yep. Hm, it looks like '@' is the char used for C++ pointer-to-member types. I'll work up a patch when I get the chance (shouldn't take too much effort). Can you file a bug? J |
|
From: George S. <st...@kd...> - 2004-03-05 01:38:30
|
On Thursday 04 March 2004 20:15, Jeremy Fitzhardinge wrote: > On Thu, 2004-03-04 at 15:52, George Staikos wrote: > > As a followup, with the latest PPC patch and this patch applied, things > > work better, but are still quite broken. The simple 'cout << "Hello > > world"' app now works fine (no errors reported), but with the Qt > > examples/hello demo I get 30000: > > ==26698== Conditional jump or move depends on uninitialised value(s) > > Well, I wonder if Paul's accurate validity checking for add will help > this? > > > At startup I also see: > > > > @@ expected ';' at type attrib (ptr="(99,1),(8,12)") > > @@ unlikely looking definition in unparsed remains > > "(0,219)=@(99,1),(8,12)" > > > > I saw this yesterday when I tried the size <= 0 patch too. > > OK, that's different - it's something in the stabs it doesn't > understand. Can you include a bit more context? It's from libqt-mt 2.3.2 (from qt-copy in KDE CVS). That's pretty much all I have: ==4033== Reading syms from /opt/qt-copy/lib/libqt-mt.so.3.2.3 @@ expected ';' at type attrib (ptr="(99,1),(8,12)") @@ unlikely looking definition in unparsed remains "(0,219)=@(99,1),(8,12)" ==4033== Reading syms from /lib/libuuid.so.1.2 Anything else specifically that I can enable to get more info? The debug flags in the stabs seem to be capable of enabling rediculous amounts of information... -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ |
|
From: Jeremy F. <je...@go...> - 2004-03-05 01:23:36
|
On Thu, 2004-03-04 at 15:52, George Staikos wrote: > As a followup, with the latest PPC patch and this patch applied, things work > better, but are still quite broken. The simple 'cout << "Hello world"' app > now works fine (no errors reported), but with the Qt examples/hello demo I > get 30000: > ==26698== Conditional jump or move depends on uninitialised value(s) Well, I wonder if Paul's accurate validity checking for add will help this? > At startup I also see: > > @@ expected ';' at type attrib (ptr="(99,1),(8,12)") > @@ unlikely looking definition in unparsed remains "(0,219)=@(99,1),(8,12)" > > I saw this yesterday when I tried the size <= 0 patch too. OK, that's different - it's something in the stabs it doesn't understand. Can you include a bit more context? J |
|
From: Paul M. <pa...@sa...> - 2004-03-05 01:17:17
|
Here are the broad outlines of the changes I made to valgrind-2.1.0 to add PowerPC support. I have made some changes since I released the original patch, so I am talking about the current patch, which is at: http://ozlabs.org/~paulus/valgrind-2.1.0-ppc.patch.bz The major changes were the creation of the PPC versions of VG_(disBB) and VG_(emit_code), in vg_ppc_to_ucode.c and vg_ppc_from_ucode.c. Many of the PPC instructions could be expressed using the existing ucodes, but there were some that couldn't, so I added a set of new ucodes. (I also removed (with ifdefs) some of the existing x86 ucodes (the MMX/SSE ones and the segment ones) to reduce code size, but this isn't strictly necessary.) PowerPC is a RISC load/store architecture with 3-address arithmetic and logical instructions, so it maps reasonably well onto ucode. Since ucode arithmetic/logical instructions are 2-address, we end up generating some extra MOVs, but those get eliminated in the ucode-to-ppc instructions step. Since arithmetic/logical instructions operate on registers, and in particular on the whole register, the size field of the corresponding uinstrs is always 4. In other words, I don't need to handle ADDB and ADDW, just ADDL. There were substantial changes to the set of things that get put in VG_(baseBlock). Obviously we have a PowerPC register set in there instead of an x86 set. There isn't any particular distinction between compact and noncompact slots on PowerPC because the load and store instructions have a 16-bit (sign-extended) offset field, so we can get to any word within 32kB of the start of VG_(baseBlock) as easily as any other. In fact I didn't end up needing many helpers. Similarly there were changes to the set of registers stored in the thread state structure. I included the floating point registers in the thread state but not in VG_(baseBlock). The FP registers are loaded from the thread state at the first use of floating point since the thread was scheduled. When switching away from the thread, I save the real FP registers into the thread state. This works because I compile valgrind with -msoft-float, which ensures that gcc doesn't use the FP registers in valgrind code. One of the areas that needed a lot of changes was the handling of flags and jump conditions. X86 has a "flags" register which bundles up condition codes (Z, S), carry (C, A) and overflow (O) bits, together with some other stuff. PowerPC handles this a bit differently. There is a 32-bit condition register (CR) which has 8 4-bit fields, labelled CR0 to CR7. Each 4-bit field can express the result of a comparison. The first 3 bits are called LT (less than), GT (greater than) and EQ (equal). The fourth bit is SO (summary overflow), and is copied from the SO bit in XER (which I describe below) when the other bits are set. Compare instructions can set any of the 8 fields, and come in signed and unsigned flavours, and set only one of LT, GT, EQ, and clear the other two. The conditional branch instructions can branch depending on whether any one of the 32 bits in CR is zero or one. Thus instead of having one type of compare (which is basically a subtract) and two sets of conditional branches (for signed and unsigned relations) as x86 does, PowerPC has two types of compare and one type of conditional branch. The conditional branches test just one bit in the CR instead of branching on a complex combination of the flag bits. Most instructions that do some arithmetic or logical operation can optionally set CR0 based on a signed comparison of the result with 0. There is a bit in the instruction (in almost all cases) that indicates whether to set CR0 or not. PowerPC also has an "integer exception register" called XER. It is 32 bits. The top 3 bits are SO (summary overflow), OV (overflow) and CA (carry). Instructions that do addition or subtraction can optionally detect overflow and clear or set the OV bit, and set the SO bit. Addition and subtraction instructions can also optionally set the CA bit to the carry-out of the addition, and optionally use CA as the carry-in. Because the setting of the carry, overflow and condition results is optional, we don't need to do any lifetime analysis on those bits. In general the instruction won't ask those bits to be set unless they are going to be used, so if the instruction says to set those bits, we just set them. In fact I have never seen the overflow-detecting forms used. In the PowerPC port, I have valid bits for each bit of CR and XER. I have GETVF and PUTVF get/set the valid bit for XER.CA. For compares and instruction forms which set CR0, I currently say that all of LT, GT and EQ are invalid if any bit of either operand (for compare instructions) or the result is invalid. That is quite conservative. When setting CR0, we know that LT is valid if the top bit of the result is valid, for instance. Another point where x86 and PowerPC differ is in the conventions for calling procedures. PowerPC has 32 general-purpose registers (GPRs) and passes the first 8 parameters to a function in R3 - R10. The return value is returned in R3 (or R3 and R4 if the function returns a long long). Functions are called using the "bl" (branch and link) instruction, which sets LR (link register) to the address of the next instruction after the bl. Functions have to save and restore LR if they call other functions, and return with a "blr" (branch to link register) instruction. By convention, R1 is used as the stack pointer. R1 always points to the bottom of the current stack frame, and the word pointed to by R1 always contains the address of the next stack frame. In other words, R1 is only changed to create a new stack frame, destroy a stack frame, or expand the current stack frame for alloca(). The differences in function calling conventions have implications for the stack tracing code, the code that sets up a new thread, the signal handling code, the code that starts GDB, etc. The code that gets the argument pointer on a client request and passes the result back is also affected. Most system calls are very similar between x86 and PowerPC, although many have different system call numbers. The calling convention is that the system call number is in R0, with parameters in R3 - R8. The return value is in R3, with an error indicator in CR0.SO. If CR0.S0 is set, then R3 contains the (positive) error number. There are some system calls (e.g. mmap) where x86 puts the arguments in memory and passes a pointer to that block of memory but PPC just passes the arguments in registers. Also, some of the kernel types are different; for example uid_t and gid_t are 32-bit, not 16-bit. Most of the bit definitions are identical, except for a few things like O_DIRECT and O_DIRECTORY. Atomic operations and spinlocks are different. PowerPC has "load with reservation" and "store conditional" instructions. The "load with reservation" establishes a reservation on the address used for the load (in fact on the cache line containing that address), and "store conditional" will only do the store if the reservation still exists (and it sets CR0 to say whether it did the store or not). Stores to that cache line from other processors will cancel the reservation. Thus you can read a value, modify it, and write back the modified value in a fashion that is effectively atomic. In valgrind I currently use a LOCK uinstr followed by a LOAD or STORE to express the load-with-reservation and store-conditional instructions. The computation of valid bits for memory loads has changed slightly. Because PowerPC load instructions always set all 32 bits of the destination register, regardless of whether it is a 1-byte, 2-byte or 4-byte load, I changed MC_(helperc_LOADV1) and friends to set the high bits of the result to 0 rather than 1. Things I changed in the existing uInstrs include: * The condition values for the JMP instruction. On PowerPC, condition values 0 .. 31 mean jump if that bit of CR is 0. Values 32 .. 63 mean jump if bit (cond & 0x1f) of CR is 1. Value 64 means jump unconditionally. The uInstrs I added are: CMP and CMPU: signed and unsigned comparison. CMP0: signed comparison against 0, for instructions that set CR0. SETZ: computes (x? 0: -1). Used in conjunction with JIFZ for the branch instruction forms that decrement the CTR. ICRF: insert condition register field. Sets 4 bits of the destination. Used for instructions that set a CR field. XBIT: extract bit. Does dst = (src >> n) & 1. Used in CR-logical instructions (ands, ors, etc. between bits of CR). IBIT: insert bit. Does dst = (dst & ~(1 << n)) | ((src & 1) << n). Used in CR-logical instructions. MULH, UMULH: signed and unsigned multiply, giving the high 32 bits of the 64-bit product. DIV, UDIV: signed and unsigned 32-bit divide. CNTLZ: count leading zeroes. Computes the number of zeroes to the left of the most-significant 1 bit in the source (or 32 if the source operand is 0). Just recently I have added three new tag ops: Tag_Min4_QT, Tag_Max4_QT and Tag_Cmp0_TQ. The first two are used in computing the exact valid bits for ADD operations. They compute (A & ~B) and (A | B) respectively. Tag_Cmp0_TQ computes the validity of the 4-bit condition result from comparing a value with 0. Minor changes included: * Changed __attribute__((regparm(N))) to asmlinkage, and defined that as an empty macro on PPC, to eliminate compiler warnings. * Moved VG_(helper_offset) from vg_from_ucode.c to vg_main.c so that I didn't have to duplicate it in vg_ppc_from_ucode.c. * Changed remove_if_exeseg_from_list() to handle removal of parts of executable segments. |