On Dec 20, 2007 10:31 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>
> Looks good to me.
>
> Are you sure that's everything? My memory was that the problems
> were with signal handlers and things, but maybe those have all
> been fixed now?
>
> Tom
>
What I had noticed for signal handlers is that VG_
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-21 03:15:03 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ..
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-21 03:05:10 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ...
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-21 03:10:05 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... f
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-21 03:00:02
GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests
I wonder if Valgrind needs to have the Wine loader built in?
Regards,
Robert.
On Dec 20, 2007, at 5:26 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
>
>> So the wine folks do much the same as we do - wine-preloader is run,
>> which is a static executable linked to load at a high address. That
>
> So the wine folks do much the same as we do - wine-preloader is run,
> which is a static executable linked to load at a high address. That
> then mmaps everything from 0 up to 1.5Gb before acting as an ELF
> loader and loading the real wine executable and it's shared libraries
> into memory and
Author: sewardj
Date: 2007-12-21 01:24:59 + (Fri, 21 Dec 2007)
New Revision: 7304
Log:
Add a new method VG_(record_depth_1_ExeContext), a trivial derivative
of VG_(record_ExeContext), which just records the first stack frame
but does not attempt to unwind the (guest) stack. This is useful in
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-21 02:00:02 CET
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... f
In message <[EMAIL PROTECTED]>
"Bart Van Assche" <[EMAIL PROTECTED]> wrote:
> There is a small inconsistency in the Valgrind core with regard to the
> value of VG_(running_tid) concerning client memory accesses: this
> variable contains a valid thread ID for all client memory accesses,
>
Hello Julian,
There is a small inconsistency in the Valgrind core with regard to the
value of VG_(running_tid) concerning client memory accesses: this
variable contains a valid thread ID for all client memory accesses,
except for some accesses triggered from coregrind/m_main.c. The
attached patch
On Dec 20, 2007 10:47 AM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> I have recently been working on trying to get valgrind and wine to
> work together
Yay!
> I've read Dan Kegel's information at
> http://wiki.winehq.org/Wine_and_Valgrind and looked at his patch but
> it doesn't address the issue I'
I have recently been working on trying to get valgrind and wine to
work together and have run into a rather nasty problem.
I've read Dan Kegel's information at
http://wiki.winehq.org/Wine_and_Valgrind and looked at his patch but
it doesn't address the issue I'm having.
The basic problem is that w
On Wed, 19 Dec 2007, Vince Weaver wrote:
> I've updated my Simpoint Basic Block Vector generating plugin to work with
> Valgrind 3.3.0
> http://www.csl.cornell.edu/~vince/projects/valsim/
>
> I was wondering what the criteria are for becoming an official
> experimental plugin that is included in
14 matches
Mail list logo
