Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-22 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-22 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-22 03:10:04 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-22 03:00: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 g5 ( SuSE 10.1, ppc970 ) started at 2007-12-22 02:00:01 CET
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... f
On Dec 21, 2007 4:47 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>
> Bart Van Assche <[EMAIL PROTECTED]> wrote:
>
> > What happens is the following:
> > * Core changes VG_(running_tid).
> > * Core notifies tool about client memory accesses.
> > * Core calls VG_T
In message <[EMAIL PROTECTED]>
Bart Van Assche <[EMAIL PROTECTED]> wrote:
> On Dec 21, 2007 10:04 AM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>>
>> Surely if it was changed before VG_TRACK(start_client_code)() then it
>> would have been fine for it to cache it?
>>
>> Did you mean that it was
On Dec 21, 2007 10:04 AM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>
> Surely if it was changed before VG_TRACK(start_client_code)() then it
> would have been fine for it to cache it?
>
> Did you mean that it was changed after that tracking call but before
> the code in the handler was executed?
What
Author: tom
Date: 2007-12-21 10:24:24 + (Fri, 21 Dec 2007)
New Revision: 7305
Log:
Propagate the ucontext information with a received signal to the
signal frame constructors and use it (on x86 and amd64) to fill in
the trap number in the signal context information.
Needed for wine which likes
In message <[EMAIL PROTECTED]>
Tom Hughes <[EMAIL PROTECTED]> wrote:
> I have recently been working on trying to get valgrind and wine to
> work together and have run into a rather nasty problem.
Unprelinking libwine has temporarily got me past the other problem, and
sorting out the trapn
In message <[EMAIL PROTECTED]>
Bart Van Assche <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 10:31 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
>
>> 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 n
In message <[EMAIL PROTECTED]>
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
>> then mmaps everything from 0 up to 1.5Gb before acting as an ELF
>> load
12 matches
Mail list logo