On Feb 9, 2008 7:25 PM, Philippe Waroquiers
<[EMAIL PROTECTED]> wrote:
> The gdb documentation looks reasonably clear at first sight, but of course
> it does not mean that it is correct and/or that the implementation of the
> protocol
> is correct. At what time did you work with this remote protoc
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-02-10 03:15:13 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 aston ( x86_64, Fedora Core 5 ) started at 2008-02-10 03:20:11
GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-02-10
03:25:09 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests
On Saturday 09 February 2008 17:17, Bart Van Assche wrote:
> On Feb 9, 2008 3:46 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
> > > I'm afraid something is wrong with one of the last commits. When I run
> > > the regression tests, on some systems all regression tests run fine
> > > and on other sys
From: "Bart Van Assche" <[EMAIL PROTECTED]>
Sent: Saturday, February 09, 2008 1:03 PM
> <[EMAIL PROTECTED]> wrote:
>> The idea is to implement in the valgrind core the "target" side of the
>> gdb
>> remote debugging protocol
>
> If you do this it is probably wise to try to find solid documentation
On Feb 9, 2008 3:46 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
>
> > I'm afraid something is wrong with one of the last commits. When I run
> > the regression tests, on some systems all regression tests run fine
> > and on other systems all regression tests hang.
>
> I did do a complete rebuild a
Author: sewardj
Date: 2008-02-09 14:51:41 + (Sat, 09 Feb 2008)
New Revision: 7388
Log:
Make exp-drd regression tests succeed when glibc-debuginfo is
installed. (Bart Van Assche)
Modified:
trunk/exp-drd/tests/filter_stderr
Modified: trunk/exp-drd/tests/filter_stderr
===
> I'm afraid something is wrong with one of the last commits. When I run
> the regression tests, on some systems all regression tests run fine
> and on other systems all regression tests hang.
I did do a complete rebuild and regression test run before committing.
The usual cause of strangeness af
Hello Julian,
I'm afraid something is wrong with one of the last commits. When I run
the regression tests, on some systems all regression tests run fine
and on other systems all regression tests hang.
I can reproduce this issue by running the commands below on an
openSUSE 10.3 x86_64 system:
$ sv
Author: sewardj
Date: 2008-02-09 12:07:40 + (Sat, 09 Feb 2008)
New Revision: 7387
Log:
Only build the SSSE3 tests on machines whose assemblers know about
these instructions.
Modified:
trunk/configure.in
trunk/none/tests/amd64/Makefile.am
trunk/none/tests/x86/Makefile.am
Modified:
On Feb 9, 2008 10:24 AM, Philippe Waroquiers
<[EMAIL PROTECTED]> wrote:
> The idea is to implement in the valgrind core the "target" side of the gdb
> remote debugging protocol
If you do this it is probably wise to try to find solid documentation
of the gdb remote debugging protocol. I have used g
On Friday 08 February 2008 16:17, [EMAIL PROTECTED] wrote:
> Author: tom
> Date: 2008-02-08 15:17:07 + (Fri, 08 Feb 2008)
> New Revision: 7383
>
> Log:
> Make the clone system call wrappers call VG_(register_stack) to record
> the new thread's stack, then make the stack unwinder use that inform
Hello,
When an error is detected by valgrind, --db-attach allows the user to look at
the client being run.
As far as I understand, the started gdb can only be used to look at the client
memory. I think
this has a.o. the following limitations:
* the usual gdb commands (break, continue, next, s
14 matches
Mail list logo
