You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(3) |
|
2
(1) |
3
(1) |
4
(2) |
5
(5) |
6
(4) |
7
(4) |
8
(6) |
|
9
|
10
(3) |
11
(6) |
12
(3) |
13
(2) |
14
(2) |
15
|
|
16
|
17
(7) |
18
(2) |
19
(15) |
20
(9) |
21
(5) |
22
(3) |
|
23
(5) |
24
(3) |
25
(3) |
26
(4) |
27
(5) |
28
(16) |
29
(7) |
|
30
|
31
(5) |
|
|
|
|
|
|
From: Alex B. <ker...@be...> - 2006-07-19 09:22:53
|
Hi, Running on 3.2.0 I came across this error. Unfortunately we only hit it a every now and again so I've not been able to replicate on the subversion version. Is there a changelog in Subversion that lists what has changed or are diffs the only way? Anyway the instruction was: (gdb) x/5i 0x70198EC2 0x70198ec2 <func+407>: lock cmpxchg %al,3595383(%rip) 0x70198eca <func+415>: test %eax,%eax (gdb) x/16x 0x70198EC2 0x70198ec2 <func+407>: 0xf0 0x0f 0xb0 0x05 0x77 0xdc 0x36 0x00 0x70198eca <func+415>: 0x85 0xc0 0x75 0xf2 0xeb 0x0c 0x49 0x8b -- Alex, homepage: http://www.bennee.com/~alex/ "I have made this letter longer than usual because I lack the time to make it shorter." -- Blaise Pascal |
|
From: Nicholas N. <nj...@cs...> - 2006-07-19 01:30:17
|
On Wed, 19 Jul 2006, Josef Weidendorfer wrote: >> ps: can anyone tell me why we install libvex.a and libcoregrind.a? They >> don't seem useful. > > They are needed for external tools to be compilable with a valgrind > installation, together with the public header files and the valgrind.pc > file. Ah, yes. Thanks. Nick |
|
From: Josef W. <Jos...@gm...> - 2006-07-19 00:47:29
|
On Wednesday 19 July 2006 02:06, Nicholas Nethercote wrote: > ps: can anyone tell me why we install libvex.a and libcoregrind.a? They > don't seem useful. They are needed for external tools to be compilable with a valgrind installation, together with the public header files and the valgrind.pc file. Distributions probably should put these into a valgrind-devel package. Back when callgrind was external, I requested the libs to be installed, as they are needed to create the static tool binary. For callgrind this is moot now, but installing them as part of a VG developer package IMHO is good practice. Josef |
|
From: Nicholas N. <nj...@cs...> - 2006-07-19 00:06:10
|
On Tue, 18 Jul 2006, Ragupathi wrote: > I want to load valgring into the target embedded board, PPC with > montavista linux. the target board contains only 32 MB RAM. is there is a way to > reduce the size of valgrind binary below 10 MB . Probably. In the $INSTALL/lib/valgrind-$PLATFORM directory you'll see something like this: cachegrind* libcoregrind.a none* vgpreload_memcheck.so* callgrind* libvex.a vgpreload_core.so* helgrind* massif* vgpreload_helgrind.so* lackey* memcheck* vgpreload_massif.so* Each tool (cachegrind, memcheck, etc) is actually a separate binary. Delete the ones you don't need -- eg. if you only want to run Memcheck, you can delete cachegrind, callgrind, helgrind, lackey, massif, none, vgpreload_helgrind.so, vgpreload_massif.so. You can also delete libvex.a and libcoregrind.a. On my system that reduces the size of the $INSTALL directory from 30MB to 5MB. Nick ps: can anyone tell me why we install libvex.a and libcoregrind.a? They don't seem useful. |
|
From: Adam S. <ad...@sp...> - 2006-07-18 23:27:50
|
Hi, I'm currently writing a program that uses dlopen() to play with shared libs, and valgrind is giving me some errors, the first of which is an "Invalid read of size 4" error. I'm pretty sure I'm not doing anything wrong in my code. I've checked as much as I can that I'm building both the library and the code that accesses it properly. I've checked the BTS and couldn't find any mention of this problem there[0]. I've also checked the list archives[1], and the best results (numbers 1 and 4 in the search I got) were unanswered[2] and what looks like user error[3] (I'm not getting SEGV). Attached is a minimal testcase that exhibits the error. It's a shell script that writes two tiny (< 10 line) c files, compiles them and runs the result. Note that the program appears to run fine and returns the correct value. I'm running "valgrind-3.2.0-Debian" on an up-to-date Debian testing system. (libc6 2.3.6-15, kernel 2.6.15-8, more system info is available on request.) Any help, including independent confirmation, fixes to gcc invocation, fixes to code, pointers to other lists/btss, gratefully received. Cheers, Adam Spragg [0]http://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=dlopen&long_desc_type=allwordssubstr&long_desc=&product=valgrind&bugidtype=include&bug_id=&votes=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&order=Bug+Number&cmdtype=doit [1]http://search.gmane.org/?query=dlopen&email=&group=gmane.comp.debugging.valgrind&sort=relevance&DEFAULTOP=and&query= [2]http://sourceforge.net/mailarchive/forum.php?thread_id=9839524&forum_id=32038 [3]http://sourceforge.net/mailarchive/forum.php?thread_id=7944833&forum_id=32038 -- To describe religions as mind viruses is sometimes interpreted as contemptuous or even hostile. It is both. -- Richard Dawkins - "A Devil's Chaplain" |
|
From: Ragupathi <rag...@ya...> - 2006-07-18 21:30:13
|
Hi everyone,
I want to load valgring into the target embedded board, PPC with
montavista linux. the target board contains only 32 MB RAM. is there is a way to
reduce the size of valgrind binary below 10 MB .
Thanks
|
|
From: Nicholas N. <nj...@cs...> - 2006-07-17 13:29:52
|
On Mon, 17 Jul 2006, Julian Seward wrote: > One question. I was just looking to see what documentation of > mem pools does currently exist. I fell across VALGRIND_MALLOCLIKE_BLOCK > and VALGRIND_FREELIKE_BLOCK. Do you have any idea how these interact > with leak checking, if at all (or even what they do?) Any block marked as a heap block with VALGRIND_MALLOCLIKE_BLOCK gets leak-checked just like any other. Nick |
|
From: Julian S. <js...@ac...> - 2006-07-17 11:43:10
|
> This patch supplies a new client request for trimming a mempool to a > specific range. Chunks contained in the range are preserved, chunks > outside the range are released, chunks only partially intersecting the > range are resized. This also looks good to me. J |
|
From: Julian S. <js...@ac...> - 2006-07-17 11:41:06
|
Hi Graydon. Nice work. > memory extents being searched are of the form [data, data+size], when I > believe their actual form is [data, data+size). That is: not including > the end-point byte at data+size. I'm hesitant to say these are true bugs > because if they are, they're quite serious, and I'm surprised they > haven't been identified already. It does seem wrong. My guess as to why this hasn't been noticed before is that the leak checker only looks for pointers in word-aligned locations. Typically, if blocks have a word-aligned size, then looking at one byte too many means that last byte will not be the start of a naturally-aligned word. > Next, pools. The issue of how to leak-check a memory pool is sort of > complicated. I'll use the following terminology below: Useful side effect is, we've never had any documentation on mempools before, afaics, which is really bad. Just the description itself is useful. > Anyone interested in merging this? I *think* the only affects I'm seeing > on the regression testsuite are either improvements in leak detection or > idiosyncrasies of my OS. I'm in favour of merging it. One question. I was just looking to see what documentation of mem pools does currently exist. I fell across VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK. Do you have any idea how these interact with leak checking, if at all (or even what they do?) Did you find any interesting leaks in Mozilla once you had this lot working? J |
|
From: <dou...@so...> - 2006-07-17 11:12:25
|
val...@li... wrote on 2006-07-17 11:52:15: > The ./configure command runs fine, and executes config.status at the end. > The make command, however, continues to run config.status in an infinite > loop. > > Help is required urgently on this problem! Just a thought: Check the system time, in particular compare the current system date&time to the configure scripts modification date. make might be trying to make the Makefile until it is newer that the configure script. -- Douglas Leeder |
|
From: Julian S. <js...@ac...> - 2006-07-17 11:11:11
|
> Well here is an segment of example of code that failed before I added a
> special sub for -O0 builds.
>
> void MyClass::setIfCondition_Zero(uint8_t &condStatus, uint64_t eflags)
> {
> __asm__ volatile
> (
> #ifdef OPTIMIZE
> #if OPTIMIZE==0
> "sub $0x10, %%rsp\n\t"
> #endif
> #endif
> "pushf \n\t"
> "push %1 \n\t"
> "popf \n\t"
> "setz %0 \n\t"
> "popf \n\t"
>
> : "=r"(condStatus): "r"(eflags));
>
> }
Alex
Are you sure this is a gcc bug? It strikes me that your inline
asm, although valid on x86, is in violation of the amd64-ELF ABI
and so is invalid.
Reason is amd64-ELF defines the 128 bytes below rsp
(viz, -128(rsp) .. -1(rsp)) as a scratch area which the compiler
can use at any time. Your asm will trash it and gcc will never
be able to know that.
In order to fix this you need to clear the scratch area, and so
you need to sub $0x80 from %rsp at the start and add it back on
later. The fact that it works without that at >= -O1 just seems
like luck to me - presumably in those cases gcc does not have
anything live in that region of the stack at the point your
asm is used.
J
|
|
From: Julian S. <js...@ac...> - 2006-07-17 10:52:30
|
> The ./configure command runs fine, and executes config.status at the end. > The make command, however, continues to run config.status in an infinite > loop. > > Help is required urgently on this problem! No idea - never seen that before on any platform. J |
|
From: Julian S. <js...@ac...> - 2006-07-17 10:49:51
|
On Monday 03 July 2006 12:08, Dennis Lubert wrote: > Am Mittwoch, den 28.06.2006, 22:55 +0100 schrieb Tom Hughes: > > In message <e05...@jp...> > > Catherine Moroney <Cat...@jp...> wrote: > > That constant (in coregrind/m_aspacemgr/aspacemgr.c) controls the > > size of the array used to hold details of each chunk of memory that > > is mapped into the process address space. > > > > Unfortunately making that table dynamically sized introduces a > > circular problem of having to allocate memory in order to record > > what memory is allocated, so it has to be kept as a fixed size > > table. > > Just a rough guess without knowing what Im talking about: could you > maybe have a small fixed table, use it in the beginning and then start > dynamically allocating it? It's a nasty circular problem. The table keeps track of memory segments, including those belonging to our dynamic memory manager. Dynamic memory allocation can require more memory segments to be created. Making this dynamically allocated would give two modules inside V, both of which require the other to be initialised first. That used to be the situation and has been known to cause crashes at startup. (Almost) all other data structures in V are indeed dynamically allocated. J |
|
From: Graydon H. <gr...@po...> - 2006-07-14 23:45:43
|
Hi, This patch supplies a new client request for trimming a mempool to a specific range. Chunks contained in the range are preserved, chunks outside the range are released, chunks only partially intersecting the range are resized. This is motivated by the arena allocators in Mozilla, which support a mark/release LIFO allocation scheme in addition to whole-pool release. I've generalized slightly to a "trim to arbitrary extent" operation, because it's easier to implement and seems likely to cover the majority of pool-resizing operations in other client applications. -graydon |
|
From: Shwetha D. <shw...@ya...> - 2006-07-14 19:04:45
|
I am interested in playing with helgrind. Can you please tell me where I can obtain the package? I am using Fedora Core 5. Thanks Regards, Shwetha Harish (503)466 0221/(503)330 5665 --------------------------------- Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. |
|
From: Graydon H. <gr...@po...> - 2006-07-13 23:08:33
|
Hi,
Attached is a patch that (I think) corrects two bugs in the leak checker
and provides leak-checking functionality to memory pools. Several people
have provided this latter functionality in the past, but their patches
have rotted against your SVN head. I say "I think" because I'm not sure
exactly what the correct leak-checking behavior for memory pools *is*,
but more on that below.
First, the bugs. I believe the leak checker's binary search (and backup
linear search) algorithms are both incorrect. They both assume that the
memory extents being searched are of the form [data, data+size], when I
believe their actual form is [data, data+size). That is: not including
the end-point byte at data+size. I'm hesitant to say these are true bugs
because if they are, they're quite serious, and I'm surprised they
haven't been identified already.
So I changed them to what I think is correct: [data, data+size). If I
left them as they were, I could not convince any of my tests to produce
the correct results. I'm pretty sure these were real bugs.
Next, pools. The issue of how to leak-check a memory pool is sort of
complicated. I'll use the following terminology below:
- A typical memory pool contains an administrative structure and
a set of superblocks.
- The administrative structure contains counts and pointiers to
superblocks.
- The superblocks are carved up by pool functions to serve user
allocations.
- The user marks the administrative structure with
VALGRIND_CREATE_MEMPOOL(pool, 0, 0).
- After malloc'ing a superblock, the user marks it with
VALGRIND_MAKE_NOACCESS(sb, sb_size).
- After allocating a chunk in a superblock, the user marks it with
VALGRIND_MEMPOOL_ALLOC(pool, chunk, chunk_sz). This puts the
chunk in a hashtable associated with the pool and marks the chunk's
bytes addressable.
- After returning a chunk to the superblock, the user marks it with
VALGRIND_MEMPOOL_FREE(pool, chunk). This removes the entry from
the internal hashtable and marks the chunk NOACCESS again.
- When done with the pool, the user calls
VALGRIND_DESTROY_MEMPOOL(pool). This frees any chunks still live
and deletes the hashtable.
- An important invariant is that the unused parts of superblocks
are NOACCESS. This keeps the pointer-scanning logic from touching
garbage / recycled memory inside a superblock.
There are several leak-related things a user might simultaneously be
interested in:
- How the chunks of the pool connect up the larger pointer graph. This
is of primary importance: if the whole pool is considered a single
extent, then any pointer into the pool connects to all pointers out
of the pool, and leak checking in general is defeated.
- Whether "the pool" (the administrative structure plus all its
superblocks) has been lost. This is relevant in user code that
explicitly manages pools. They might leak the whole pool.
- Whether some number of chunks within each pool's superblocks are
allocated-but-not-pointed-to. These chunks might then be considered
"leaked". They might also *not* be considered leaked if the
surrounding pool is still reachable: some pools are designed to be
freed all at once.
While I am sympathetic to the idea of building a complicated structure
that relates each pool to its chunks using some sort of "virtual edge"
during leak checking, I am also pressed for time and wanted to see if
there was a "90%" solution that solves the important case: tracking the
pool chunks individually in the pointer graph.
I believe I've accomplished this with a relatively minor change that
only affects the initial stage of the algorithm: selecting chunks to
scan. If we let:
M = {malloc chunks}
P = {mempool chunks}
X = {c | c in M such that forall p in P, p intersect c == null}
Y = X union P
Then where previously we ran the algorithm on M, we now run it on Y.
More intuitively, this is "the set of mempool chunks" plus "the set of
malloc chunks that don't intersect mempool chunks". It's reasonably easy
to calculate this set, and it produces what I think are "more desirable"
results. Specifically:
- Each chunk in a pool is independently considered as a pointer-graph
member. A pointer into a chunk connects only to the outgoing
pointers held in the chunk.
- The leak-checker independently detects leakage of each chunk in
the pool, except the first chunk in a superblock, for which the
reference from administrative structure to superblock is considered
a reference to the chunk as well.
- The proper chunk-allocation context is reported when leaks are
found involving a chunk; not the outer pool-allocation.
- If the administrative structure is leaked from user code, it is
still reported. The count of indirect bytes leaked along with it
includes the superblocks if they are empty / unallocated. If the
superblocks contain allocated chunks, a smaller number is reported
(the size of the administrative structure alone), but there is still
a leak report.
Anyone interested in merging this? I *think* the only affects I'm seeing
on the regression testsuite are either improvements in leak detection or
idiosyncrasies of my OS.
-graydon
|
|
From: Julian S. <js...@ac...> - 2006-07-13 13:31:32
|
> Now the problem with the current error is not that the variable has > never been initialised. At some point in running it becomes > uninitialised. I think this is probably because at some point we write a > 32bit value to what is usually refereed to as a 64 bit one. Of course > what I need to find is when that 32 bit was written (or whatever made > that location uninitialised) - not when we next refer to it. > Poll it frequently with VALGRIND_CHECK_DEFINED then? or Can you use a gdb hardware watchpoint to spot the erroneous 32-bit write to that location? J |
|
From: Julian S. <js...@ac...> - 2006-07-12 22:11:12
|
> 1. How does VEX handle exceptions like #DE(divide error) on div
> instructions when the quotient is too large for the destination operand?
It doesn't. Basically anything in vex to do with exceptions is a kludge
of one kind or another. If I had it to do over it could be done cleaner.
Right now the divide insn is simply regenerated from IR by the back end;
if a divide by zero happens, a host signal will hit the generated code,
and who knows what will happen then. A better solution would be to generate
IR which tests the denominator for zero and does an IR side exit from the
BB, carrying a flag which tells the scheduler that the insn couldn't be
executed - in the same style that side exits are done if a segment override
prefix causes an addressing problem. Look for Ijk_MapFail in
guest-x86/toIR.c.
Even then, the IR representation of division is pretty half-arsed.
For one thing, on ppc, divide by zero doesn't give an exn, it just
produces an undefined result. On x86 you get an exn. So that would
have to be taken into account.
> 2. Where do you set eflags for certain instructions like add? This
> instruction: add $0x4,%eax
> Gets translated into:
> IRBB {
> t0:I32 t1:I32 t2:I32
>
> ---IMark(...)---
> t2 GET:I32(0)
> t1 = 0x4:I32
> t0 = Add32(t2,t1)
> PUT(32) = 0x3:I32
> PUT(36) = t2
> PUT(40) = t1
> PUT(44) = 0x0:I32
> PUT(0) = t0
> goto {Boring} ...
> }
> which doesn't have any assignments to any part of eflags?
In short we don't. Instead offsets 32/36/40/44 hold enough data about
the current operation to be able to calculate eflags (specifically,
the O S Z A C and P flags) later if needed. See section "Condition code
stuff" in guest-x86/gdefs.h.
> 3. How does the 4-word thunk mechanism involving CC_OP, CC_DEP1, CC_DEP2,
> and CC_NDEP work?
Have a look at big comment in guest-x86/gdefs.h line 201.
> 4. For some of these flag setting instructions (like inc) VEX reads the
> above 4 CC_ registers then calls a helper like x86g_calculate_eflags_c with
> their values passed in in order to set eflags. Why doesn't it just emit IR
> that sets those flags instead? e.g. t2 = Add32(t0, t1)
> PUT(ZF) = CmpEQ32(t2, 0)
What x86g_calculate_eflags_c is to do with is the idiocy that inc/dec
set only 5 of the flags - O S Z A P - and don't change C. Therefore to
set the thunk after inc/dec it is first necessary to compute the old C
flag, and so the old thunk components are handed off to this helper to
compute the old C flag.
You should preferably use the post-optimisation IR. The x86 IR flag
scheme is carefully set up so that the IR optimiser can knock out most
of this junk. This not only gives much more efficient IR, it also
replaces many of the helper function calls with in-line IR, which
makes the data flows much clearer. That may or may not be important
for you.
J
|
|
From: Eric L. <ew...@an...> - 2006-07-12 21:00:06
|
Hey guys,
I have some questions about the IR I'd appreciate anyone's input on.
1. How does VEX handle exceptions like #DE(divide error) on div instructions when the quotient is too large for the destination operand?
2. Where do you set eflags for certain instructions like add? This instruction:
add $0x4,%eax
Gets translated into:
IRBB {
t0:I32 t1:I32 t2:I32
---IMark(...)---
t2 GET:I32(0)
t1 = 0x4:I32
t0 = Add32(t2,t1)
PUT(32) = 0x3:I32
PUT(36) = t2
PUT(40) = t1
PUT(44) = 0x0:I32
PUT(0) = t0
goto {Boring} ...
}
which doesn't have any assignments to any part of eflags?
3. How does the 4-word thunk mechanism involving CC_OP, CC_DEP1, CC_DEP2, and CC_NDEP work?
4. For some of these flag setting instructions (like inc) VEX reads the above 4 CC_ registers then calls a helper like x86g_calculate_eflags_c with their values passed in in order to set eflags. Why doesn't it just emit IR that sets those flags instead?
e.g. t2 = Add32(t0, t1)
PUT(ZF) = CmpEQ32(t2, 0)
Thanks,
Eric
|
|
From: Dennis L. <pla...@pr...> - 2006-07-12 09:27:43
|
Am Dienstag, den 11.07.2006, 13:38 -0400 schrieb James Renton: > I was perusing the documentation for Valgrind as I get acquanted with > it. >=20 > =20 >=20 > In the section on suppressions, I noticed that the error is identified > using the following string: >=20 > =20 >=20 > =E2=80=9CMemcheck:Value4=E2=80=9D >=20 > =20 >=20 > But, in the log that the tool generates, it prints something like: >=20 > =20 >=20 > =E2=80=9CUse of uninitialised value of size 4=E2=80=9D >=20 > =20 >=20 > How does one figure out that to suppress this error, you use > Memcheck:Value4. Ie. where can I find the mapping between this > identifier and the error message? >=20 The --gen-suppressions parameter to valgrind is there to help generating suppressions. >=20 |
|
From: Bryan M. <om...@br...> - 2006-07-11 19:10:35
|
Dear All, Just a quick note to let you know that there is a beta 4b on the website - I borked the function wrapper around main() and unfortunately, only tested on AMD64 (where it didn't cause my test program to segfault horribly). This is fixed now and I recommend everyone that has tried the beta 4 patch to upgrade (mainly because this one works and the other one didn't ;). Thank you for the bug reports, please keep them coming. Sorry for the inconvenience. Bryan "Brain Murders" Meredith Bryan Meredith wrote: > please see http://www.brainmurders.eclipse.co.uk/omega.html for a > complete overview of what this tool can do for you! > > (We use this heavily at work - feel free to give it a spin...) > > >>From the web page: > ================== > Omega addresses what I perceive to be one of the few shortfalls of the > excellent Valgrind Memcheck Tool - where Memcheck reports the location > that a leaked block was allocated, Omega also shows where it was leaked. > > > New in Beta4: > ============= > Bug fix in circular reference detection. > Function wrappers around memcpy(), memmove() and memset(). > More robust detection of functions returning values in the accumulator > (fixes a false positive). > > > Known Issues: > ============= > I have a wrapper around main() to detect when to stop tracking - if you > are using threads and they don't exit before main() does, there will be > problems. I haven't particularly tested this with threads yet - that's > targeted for the next beta. > > > Requested Features? > =================== > I am still toying with the idea of allowing targeted tracking through > the use of the suppression system - > > exclusively report on a specified malloc() call. > show hanging pointers at a targeted call to free(). > turn on more verbose output for a given memory block. > > Generate leak reports in some XML format to make machine parsing simple. > > > If you use Omega and think any of these features would be useful or have > requests of your own, please let me know. > > > > As ever, I would welcome your comments, bug reports and especially any > news of success stories. > > thanks, > Bryan "Brain Murders" Meredith > > > 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: James R. <jr...@ca...> - 2006-07-11 17:36:09
|
I was perusing the documentation for Valgrind as I get acquanted with it. =20 In the section on suppressions, I noticed that the error is identified using the following string: =20 "Memcheck:Value4" =20 But, in the log that the tool generates, it prints something like: =20 "Use of uninitialised value of size 4" =20 How does one figure out that to suppress this error, you use Memcheck:Value4. Ie. where can I find the mapping between this identifier and the error message? =20 James A. Renton Beverly, MA =20 |
|
From: Alex B. <ker...@be...> - 2006-07-11 16:55:30
|
Hi,
Not that I want to seem as though I'm monopolising the mailing list
today could I suggest an additional variant of the very useful
VALGRIND_CHECK_VALUE_IS_DEFINED() that does return a value on failure.
This would be useful for programs dumping internal state when something
goes wrong.
I have hacked something together using VALGRIND_CHECK_MEM_IS_DEFINED:
if (VALGRIND_CHECK_MEM_IS_DEFINED(&a,sizeof(MyThing)) ||
VALGRIND_CHECK_MEM_IS_DEFINED(&b,sizeof(MyThing)))
{
fprintf(stderr, "orRRR pc=0x%lx a=%d/%d, b = %d/%d\n",currentPc,
rs1,MyClass::gprToRegisterID(rs1),
rs2,MyClass::gprToRegisterID(rs2));
}
But it seems a little in-elegant somehow.
One really handy ability for use would be to dump the Valgrind binding
stream in a generated function (say in Jit'ed code). However looking at
how the binding and inline assembler I suspect this will be tricky to do
in a portable way. I'll see if I can get anything sensible working when
I've got some spare time.
--
Alex, homepage: http://www.bennee.com/~alex/
May a Misguided Platypus lay its Eggs in your Jockey Shorts
|
|
From: Alex B. <ker...@be...> - 2006-07-11 14:55:29
|
On Tue, 2006-07-11 at 14:57 +0100, Julian Seward wrote: > Two things. (1) Make sure you're using 3.2.0; that has the most > accurate uninit-value tracking shipped so far; it's better than 3.1.1. I live on the Subversion tree ;-) > (2) The fast easy way to chase down the source of uninitialised values > is with the VALGRIND_CHECK_DEFINED macro. > > #include "valgrind.h" in your code (or is it memcheck.h, I can > never remember) > > Add VALGRIND_CHECK_DEFINED(possibly_suspicious_variable); V will > then croak if the var is undefined. See > > http://www.valgrind.org/docs/manual/manual-core.html#manual-core.clientreq > and > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs > That's damn useful. I shall have to look at including that directly in our code (I can already see the allocator stuff very useful considering our use of Memory Pools). Now the problem with the current error is not that the variable has never been initialised. At some point in running it becomes uninitialised. I think this is probably because at some point we write a 32bit value to what is usually refereed to as a 64 bit one. Of course what I need to find is when that 32 bit was written (or whatever made that location uninitialised) - not when we next refer to it. -- Alex, homepage: http://www.bennee.com/~alex/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. |
|
From: Julian S. <js...@ac...> - 2006-07-11 13:57:50
|
Two things. (1) Make sure you're using 3.2.0; that has the most accurate uninit-value tracking shipped so far; it's better than 3.1.1. (2) The fast easy way to chase down the source of uninitialised values is with the VALGRIND_CHECK_DEFINED macro. #include "valgrind.h" in your code (or is it memcheck.h, I can never remember) Add VALGRIND_CHECK_DEFINED(possibly_suspicious_variable); V will then croak if the var is undefined. See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.clientreq and http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs J On Tuesday 11 July 2006 14:47, Alex Bennee wrote: > Hi, > > So it came to pass I started looking at a couple of the errors thrown up > by valgrind. This one made me blink: > > ==16647== Conditional jump or move depends on uninitialised value(s) > ==16647== at 0x700F1C29: MyClass::branchI(long, ConditionCode, bool) > (MyClass.cc:1917) > > Looking at the code it referenced: > > // Decide if we're going to take the branch > bool takeBranch = sic->createIccCondition(cond); > if(takeBranch) > { > > As I've got a lot of trust in valgrind these days I didn't dismiss it as > impossible. The reason of course is the un-initialised value is > propagating from sic->createIccCondition(cond). I've been going around > back down the line to places where the variables are set and adding: > > if (a) > { > magicValgrindValue = 0; > } else { > magicValgrindValue = 1; > } > > To try and figure out how the value became initialised. However this is > quite tedious work. Does valgrind know this information anayway? Is > there anyway to get it to tell me where the value was reset to its > initialised state from? > > -- > Alex, homepage: http://www.bennee.com/~alex/ > A great nation is any mob of people which produces at least one honest > man a century. > > > > ------------------------------------------------------------------------- > 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-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |