[Valgrind-developers] 2008-02-14 03:05:06 GMT nightly build (lloyd, x86_64, Fedora 7)

Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-02-14 03:05:06 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... fa

[Valgrind-developers] 2008-02-14 03:25:17 GMT nightly build (trojan, x86_64, Fedora Core 6)

Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-02-14 03:25:17 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests

[Valgrind-developers] 2008-02-14 03:15:03 GMT nightly build (alvis, i686, Red Hat 7.3)

Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-02-14 03:15:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... f

[Valgrind-developers] 2008-02-14 03:20:06 GMT nightly build (aston, x86_64, Fedora Core 5)

Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-02-14 03:20:06 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests

[Valgrind-developers] 2008-02-14 03:10:05 GMT nightly build (dellow, x86_64, Fedora 8)

Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-02-14 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

[Valgrind-developers] 2008-02-14 03:00:03 GMT nightly build (gill, x86_64, Fedora Core 2)

Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-02-14 03:00:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests .

[Valgrind-developers] valgrind: r7406 - branches/DATASYMS/coregrind/m_debuginfo

Author: sewardj Date: 2008-02-14 00:44:17 + (Thu, 14 Feb 2008) New Revision: 7406 Log: Primarily, try and free up at least some of the variable type info at munmap time. Only partially successful. Also, a bit more removal of duplicated code. Modified: branches/DATASYMS/coregrind/m_debu

Re: [Valgrind-developers] valgrind: r7383 - in trunk/coregrind: . m_syswrap

Tom Hughes a écrit : > In message <[EMAIL PROTECTED]> > Julian Seward <[EMAIL PROTECTED]> wrote: > > >> The business of tracking the bounds of each stack is a pain, and >> makes for fragility -- for example, does it now work correctly with >> user-defined stacks? >> > > Well it shou

Re: [Valgrind-developers] prototype in valgrind: will libc direct usage work "reasonably" for prototyping something in valgrind core ?

> As far as I understand the Valgrind core, you risk introducing all > kinds of subtle issues when you try to link the Valgrind core with > libc. Yes. Don't use libc. > In case you need a simple function from glibc, you can copy its > implementation and link it with the Valgrind core. Check

Re: [Valgrind-developers] prototype in valgrind: will libc direct usage work "reasonably" for prototyping something in valgrind core ?

On Feb 13, 2008 7:31 PM, Philippe Waroquiers <[EMAIL PROTECTED]> wrote: > Currently, I am working on doing this because it is fun. > I understood from the doc that it is not ok to call libc or any system call > directly in valgrind core, because this > causes various subtile problems. > > Are these

[Valgrind-developers] exp-drd bug fix: fix tc18_semabuse regression test on Fedora 8

Hello Julian, Can you please apply the attached patch ? The attached patch fixes the assertion failure triggered by the tc18_semabuse test on Fedora 8. The fix consists of removing a tl_assert() statement. In this case this is OK, because what the tl_assert() statement was checking is that sem_pos

[Valgrind-developers] prototype in valgrind: will libc direct usage work "reasonably" for prototyping something in valgrind core ?

(cfr my previous mails about gdbserver protocol). Currently, I am working on doing this because it is fun. I understood from the doc that it is not ok to call libc or any system call directly in valgrind core, because this causes various subtile problems. Are these problems reasonable enough tha

[Valgrind-developers] using setjmp/longjmp in the valgrind core ?

Hello, After my post "[Valgrind-developers] obtain a debuggable client by having gdbremote protocol in valgrind core ?", I had very few reactions, which I have interpreted as enthusiastic (but silent) admiration of the idea :). So, I have started to implement it, basing the development on the

Re: [Valgrind-developers] valgrind: r7383 - in trunk/coregrind: . m_syswrap

> Well it really needs to check a range of addresses - unwinding > a stack frame on x86 using the frame pointer requires reading > a group of 8 bytes, which can cross a page boundary. Hmm, true. Still, checking for page boundary crossing is something that can be pushed into the query function.

Re: [Valgrind-developers] valgrind: r7383 - in trunk/coregrind: . m_syswrap

In message <[EMAIL PROTECTED]> Julian Seward <[EMAIL PROTECTED]> wrote: > The business of tracking the bounds of each stack is a pain, and > makes for fragility -- for example, does it now work correctly with > user-defined stacks? Well it should do so long as they are registered with the