You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Donna R. <do...@te...> - 2004-08-28 21:06:48
|
On Saturday 28 August 2004 22:00, Tom Hughes wrote: > What I meant was that it is only tags that have been changed. Lots of > instances of the word code in the text itself have been changed. thanks, yes, on further investigation you are right. mea culpa - that's what you get for not paying attention when doing search & replace. will fix asap. (blush) d |
|
From: Tom H. <th...@cy...> - 2004-08-28 21:00:48
|
In message <200...@te...>
Donna Robinson <do...@te...> wrote:
> On Saturday 28 August 2004 17:14, Tom Hughes wrote:
> > Did somebody do s/code/computeroutput/ or something? Only there
> > are lots of instances of the strange word computeroutput in that
> > documentation ;-)
>
> that's the closest I could get to <code>blah</code>
> it's not great.
What I meant was that it is only tags that have been changed. Lots of
instances of the word code in the text itself have been changed.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Donna R. <do...@te...> - 2004-08-28 20:29:42
|
On Saturday 28 August 2004 17:14, Tom Hughes wrote:
> Did somebody do s/code/computeroutput/ or something? Only there
> are lots of instances of the strange word computeroutput in that
> documentation ;-)
that's the closest I could get to <code>blah</code>
it's not great.
FYI - xml to html markup transformations:
<programlisting> --> <pre class="programlisting">
<screen> --> <pre class="screen">
<computeroutput> --> <tt class="computeroutput">
<literal> --> <tt>
<emphasis> --> <i>
<command> --> <b class="command">
<blockquote> --> <div class="blockquote">
<blockquote class="blockquote">
I claim to be a total non-expert at all this.
If anyone has better ideas, tell me please.
d
|
|
From: Tom H. <th...@cy...> - 2004-08-28 16:14:54
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> A tarball of the final results is available at
>
> http://www.dancedetails.org/vgdocs.tar.bz2
>
> This contains the generated .pdf, .ps and .html for the user manual
> and FAQ, so you can get a good idea what the result looks like.
Did somebody do s/code/computeroutput/ or something? Only there
are lots of instances of the strange word computeroutput in that
documentation ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Donna R. <do...@te...> - 2004-08-28 15:33:20
|
On Saturday 28 August 2004 16:08, Bob Friesenhahn wrote: > OpenOffice already uses XML format for its document files. At this point I think OO can only deal with DOCTYPE article. Most of the vg-docs are DOCTYPE books, so no-go at present. d |
|
From: Donna R. <do...@te...> - 2004-08-28 15:31:56
|
> I'm not so keen on this -- it's totally standard for README, INSTALL, > COPYING, TODO, etc. to be in the top-level directory. Nobody will look > for them in valgrind/docs/dist_files/. sorry - I didn't explain this very well. At build-time, FAQ.txt *also* gets generated from the xml, and put into dist_files/. After the other formats are generated, the entire contents of dist_files gets moved into the top-level dir valgrind/ > As for the FAQ, it's nice to have a copy of that in the top-level > directory as well, in plain-text, if possible. see above. > > (tech docs) > > - The design and implementation of valgrind (old) > > - How cachegrind works > > - Writing a new Valgrind Tool > I'm not sure if the first two need to be in there any more. If they are, > the first should definitely be marked at the top with a big "out of date, > many details no longer true!" warning. um, well, praps *all* the docs need a facelift? > Is that the original XML, or the resulting HTML? It would be good to have > both up for viewing. This is just a tarball of files in .pdf, .ps and .html format so people can get can idea of what it all comes out like. d |
|
From: Bob F. <bfr...@si...> - 2004-08-28 15:08:27
|
On Sat, 28 Aug 2004, Julian Seward wrote: > > - One day we may be able to edit the xml masters directly in > OpenOffice (wysiwyg), which would save loads of time and effort. At > the moment, one has to edit the html and constantly reload it in a > browser to see that the right thing is happening. OpenOffice already uses XML format for its document files. Do an 'unzip -l' on an OpenOffice .sxw file to see the content. The XML is very compact and ugly, but I notice that there is a configuration option to format the XML for humans (resulting in larger files). Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Bob F. <bfr...@si...> - 2004-08-28 14:58:56
|
On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: > On Sat, 2004-08-28 at 10:57 +1000, Paul Mackerras wrote: >> In practice it seems that compiling everything with -fpic will work. > > Yes, that shouldn't be a problem; none of the code which doesn't need it > is performance critical. > >> I think that this line in coregrind/Makefile.am works more by the >> grace of GNU make than anything else: >> >> vg_replace_malloc.o vg_intercept.o vg_libpthread.o: CFLAGS += -fno-omit-frame-pointer -g -fPIC >> > I believe I've already used the phrase "teetering pile" with respect to > automake/autoconf/gmake. Is there a proper automake-ish way of doing > this? Automake allows you to set compilation flags on a per-program (or per-library) basis. A single source file can be included in several programs, and it will potentially be compiled with different flags for each program. That means if these objects are put in a library you could do: lib_vgfoopic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c lib_vgfoopic_CFLAGS=-fno-omit-frame-pointer -g -fPIC lib_vgnonpic_SOURCES=vg_replace_malloc.c vg_intercept.c vg_libpthread.c lib_vgnonpic_CFLAGS=-fno-omit-frame-pointer -g When you use this approach, the object files are given extended names in order to make sure that object files do not collide. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-08-28 14:45:58
|
On Sat, 28 Aug 2004, Julian Seward wrote: > Distribution docs in plain text format, ie. README, etc. > valgrind/docs/dist_files/ I'm not so keen on this -- it's totally standard for README, INSTALL, COPYING, TODO, etc. to be in the top-level directory. Nobody will look for them in valgrind/docs/dist_files/. As for the FAQ, it's nice to have a copy of that in the top-level directory as well, in plain-text, if possible. > (tech docs) > - The design and implementation of valgrind (old) > - How cachegrind works > - Writing a new Valgrind Tool I'm not sure if the first two need to be in there any more. If they are, the first should definitely be marked at the top with a big "out of date, many details no longer true!" warning. The rest seems good to me. > All feedback gratefully received. It would be handy for folks to > look at the results, at http://www.dancedetails.org/vgdocs.tar.bz2. Is that the original XML, or the resulting HTML? It would be good to have both up for viewing. N |
|
From: Julian S. <js...@ac...> - 2004-08-28 14:11:23
|
Greetings.
Converting the documentation into XML
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I've been looking into converting all of Valgrind's documentation into
XML. It seems to me that having the originals in html is not a good
long-term solution and that XML is a better starting format since:
- Conversion from html to other formats (pdf, dvi, ps, tex) is too
difficult, and there have been requests for the docs in those
formats.
- Using xml allows generation of the documentation in a book form,
which looks a lot more professional, is easier to use, and prints
nicely. Printing the html pages does not give what one would
normally think of as a decent manual.
- xml documents must be well-formed and validated prior to processing;
therefore all resultant html is guaranteed to be well-formed
(ie. w3c compliant), which in turns means accessible by any browser.
If invalid xml is committed, it simply won't build.
- One day we may be able to edit the xml masters directly in
OpenOffice (wysiwyg), which would save loads of time and effort. At
the moment, one has to edit the html and constantly reload it in a
browser to see that the right thing is happening.
- XML may make it easier to translate the documentation into different
languages, should that become necessary.
- XML allows consistent, checked, cross-referencing across the entire
documentation set. Similarly, out-of-date references to fixed bits
of information (old email addresses, dates, version numbers, etc)
goes away because we declare one single entity thus:
<!ENTITY vg-lifespan "2000-2004">
then everywhere we need to put copyright stuff, we can say:
Copyright (C) &vg-lifespan; Valgrind Developers
- And finally, using xml allows us to separate content from
presentation (always a Good Thing).
Changes in repo structure and build process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Roughly speaking, the changes in repo structure are as follows:
- All the html files disappear and are replaced with xml:
Docs specific to each tool:
valgrind/<toolname>/docs/<file(s)>.xml
Main /docs/ dir:
valgrind/docs/
Distribution docs in plain text format, ie. README, etc.
valgrind/docs/dist_files/
Any images used in the docs:
valgrind/docs/images/
Stylesheets, catalogs, parsing/formatting scripts:
valgrind/docs/lib/
Top-level xml files: docs/xml/
vg-bookset.xml: top-level bookset wrapper
faq.xml, howto.xml: also kept in here.
vg-entities.xml: various strings, dates etc. used by the various docs
tool-template.xml: template file for writing new tool docs.
xml-hints: quick reference for frequently-used xml tags.
- The build process is entirely driven from a single Makefile in
valgrind/docs/. Building documentation is done by:
(cd docs && make target)
where target is one of html, pdf, ps, or all.
What you get
~~~~~~~~~~~~
What you get is a sequence of "books", where each book is a
self-contained entity, with its own table of contents, and index if
you want. Linking both within and across books is consistently done.
The main books generated are:
(user docs)
- The User's Manual
- The FAQ
- The Howto
(tech docs)
- The design and implementation of valgrind (old)
- How cachegrind works
- Writing a new Valgrind Tool
(reference)
- Distribution documents (the old README* files)
- GNU General Public License
Clearly we can mash around the top-level book structure as needed, but
this seems like a good start.
A tarball of the final results is available at
http://www.dancedetails.org/vgdocs.tar.bz2
This contains the generated .pdf, .ps and .html for the user manual
and FAQ, so you can get a good idea what the result looks like.
Toolchain dependencies
~~~~~~~~~~~~~~~~~~~~~~
Some time was spent on the docbook-apps list in order to ascertain the
most-useful / widely-available / least-fragile / advanced toolchain.
Basically, everything has problems of one sort or another, so I ended
up going with what I felt was the least-problematical of the various
options.
It's unrealistic to expect end-users to have these tools available on
their systems. Therefore the plan is to have two different kinds of
build: end-user builds, and developer builds. Developers must have
the required tools, and will be able to build pdf, ps, html, etc (any
supported target). For end-users building from tarballs, we will
pre-generate the pdf/ps/html, and these will simply be copied by 'make
install', so there is no further fragility there.
Developers need to ensure the following tools are present:
XML validation
- xmllint: libxml version 20607
XML translation top-level driver (.xml -> .html or .xml -> .fo)
- xsltproc: libxml 20607, libxslt 10102 and libexslt 802
Converts .fo to .pdf
- pdfxmltex: pdfTeX (Web2C 7.4.5) 3.14159-1.10b
- and therefore TeX
Converts .pdf to .ps
- pdftops: version 3.00
DocBook (schema, DTD, style sheets, macros, etc)
- DocBook: version 4.2
Converts .html into .txt
- lynx
Needed at some point in the process
- bzip2
A big problem is latency. DocBook is constantly being updated, but
the tools available in Linux distros tend to lag behind. It is
important that the versions get on with each other. If you decide to
upgrade something, you need to ensure that things still work nicely -
something which cannot be assumed.
All feedback gratefully received. It would be handy for folks to
look at the results, at http://www.dancedetails.org/vgdocs.tar.bz2.
J
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-28 14:09:23
|
On Sat, 28 Aug 2004, Paul Mackerras wrote: >> I've rejigged my file/dir structure proposal, and started reshaping Paul's >> x86-abstraction patch accordingly. You can grab see the basics in a >> tarball at >> >> www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 > > Looks good, but you seem to have left out Makefile.all.am, > Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. Yes... strange that "make distcheck" didn't pick that up. Hmm. I've fixed it up and updated the tarball. > The rest of your proposal looks fine to me. Great, thanks for looking at it. Other comments are still welcome. N |
|
From: Tom H. <th...@cy...> - 2004-08-28 09:36:17
|
In message <166...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> I was just looking at the recent CVS commit to add these lines to
> vg_signals.c:
>
> if (sigNo == VKI_SIGFPE) {
> frame->sigInfo._sifields._sigfault._addr = (void *)tst->m_eip;
> }
>
> Are there perhaps other signals that also need this? SIGSEGV perhaps?
No, because for SEGV si_addr is the faulting address rather than the
address of the instruction that caused the fault. The faulting address
will be correct and doesn't need patching up. It's only code addresses
that need patching or they will point to the JITed code.
I think it's only SIGFPE that puts the instruction address there, but
shout if you find anything else that does.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Chris J. <ch...@at...> - 2004-08-28 09:17:41
|
> On Sat, 2004-08-28 at 11:09 +1000, Paul Mackerras wrote: > > I would think that V would have a socket open to gdb. We > would drop > > the number of BBs that get executed in a bunch from 50000 > to say 1000 > > or less. We would put a poll or select call in the > scheduler to check > > for stuff from gdb, and if there is stuff, we call the gdbstub code. > > Yes, the idle() function already does a poll() to see if > there's anything interesting to do, so adding a gdb > connection socket fd is trivial. > > > That can read/write memory and cpu registers by itself just > fine, and > > if it wants to suspend execution for a while, it just does > a blocking > > read on the socket. If it wants to write a breakpoint, it > writes it, > > and calls a routine from vg_transtab.c to invalidate any > translation > > of the code where the breakpoint is set. > > If the code you're breakpointing has already been translated, > you could probably pretty easily modify the translated code > in-place to do the breakpoint. > > > The remaining thing is single-stepping. Here I think the > thing is for > > the gdbstub routine to return a code to the scheduler indicating > > single-stepping, after having invalidated the translation > (if any) for > > the current eip. That sets a 'single-stepping' flag, and > on the next > > call to VG_(translate) we pass a parameter (a new parameter) > > indicating that we want it to translate at most one > instruction. We > > execute that and then call the gdbstub again. We probably > also need a > > new return code from run_thread_for_a_while to indicate > that we have > > hit a breakpoint instruction. > > There's already a --single-step=yes option, which translates > every instruction as its own basic block. You could just > implicitly set that when you enable the gdb server. I've already solved the problems associated with inserting breakpoints, single stepping etc. (see http://www.atomice.com/gdb-valgrind.html). Chris |
|
From: Paul M. <pa...@sa...> - 2004-08-28 09:11:43
|
I was just looking at the recent CVS commit to add these lines to
vg_signals.c:
if (sigNo == VKI_SIGFPE) {
frame->sigInfo._sifields._sigfault._addr = (void *)tst->m_eip;
}
Are there perhaps other signals that also need this? SIGSEGV perhaps?
Paul.
|
|
From: Paul M. <pa...@sa...> - 2004-08-28 08:19:42
|
Nicholas Nethercote writes: > I've rejigged my file/dir structure proposal, and started reshaping Paul's > x86-abstraction patch accordingly. You can grab see the basics in a > tarball at > > www.cl.cam.ac.uk/~njn25/vg-arch.tar.bz2 Looks good, but you seem to have left out Makefile.all.am, Makefile.tool.am and Makefile.core-AM_CPPFLAGS.am. The rest of your proposal looks fine to me. Paul. |
|
From: Jeremy F. <je...@go...> - 2004-08-28 05:58:40
|
On Sat, 2004-08-28 at 10:57 +1000, Paul Mackerras wrote: > In practice it seems that compiling everything with -fpic will work. Yes, that shouldn't be a problem; none of the code which doesn't need it is performance critical. > I think that this line in coregrind/Makefile.am works more by the > grace of GNU make than anything else: > > vg_replace_malloc.o vg_intercept.o vg_libpthread.o: CFLAGS += -fno-omit-frame-pointer -g -fPIC > > I believe that automake gives up on thinking it knows anything about > those object files at that point and we end up relying on make's > implicit rules. I say this because I tried to add an object to that > line whose source was in a subdirectory, and at that point make could > no longer find the source for that object. Looking in the generated > Makefile I saw that where automake had previously generated a > dependency and rule to generate the object from the source in the > subdirectory, that dependency and rule was now commented out. I believe I've already used the phrase "teetering pile" with respect to automake/autoconf/gmake. Is there a proper automake-ish way of doing this? J |
|
From: Jeremy F. <je...@go...> - 2004-08-28 05:53:53
|
On Sat, 2004-08-28 at 11:09 +1000, Paul Mackerras wrote: > I would think that V would have a socket open to gdb. We would drop > the number of BBs that get executed in a bunch from 50000 to say 1000 > or less. We would put a poll or select call in the scheduler to check > for stuff from gdb, and if there is stuff, we call the gdbstub code. Yes, the idle() function already does a poll() to see if there's anything interesting to do, so adding a gdb connection socket fd is trivial. > That can read/write memory and cpu registers by itself just fine, and > if it wants to suspend execution for a while, it just does a blocking > read on the socket. If it wants to write a breakpoint, it writes it, > and calls a routine from vg_transtab.c to invalidate any translation > of the code where the breakpoint is set. If the code you're breakpointing has already been translated, you could probably pretty easily modify the translated code in-place to do the breakpoint. > The remaining thing is single-stepping. Here I think the thing is for > the gdbstub routine to return a code to the scheduler indicating > single-stepping, after having invalidated the translation (if any) for > the current eip. That sets a 'single-stepping' flag, and on the next > call to VG_(translate) we pass a parameter (a new parameter) > indicating that we want it to translate at most one instruction. We > execute that and then call the gdbstub again. We probably also need > a new return code from run_thread_for_a_while to indicate that we have > hit a breakpoint instruction. There's already a --single-step=yes option, which translates every instruction as its own basic block. You could just implicitly set that when you enable the gdb server. > That should just about do it. For extra marks, we could subsequently > implement "hardware" instruction and data address breakpoints. :) Robert Walsh already has some watchpoint machinery. J |
|
From: Paul M. <pa...@sa...> - 2004-08-28 04:37:59
|
I have put a tarball of the current state of my PPC Valgrind port at: http://ozlabs.org/~paulus/valgrind-2.1.3-CVS-ppc-040827.tar.bz2 This is based on Valgrind CVS as of about Wednesday or Thursday this week. This is very much an interim release; the code and the locations of files are going to change as we continue to move towards merging the PPC port with the mainstream Valgrind code. However, it seems to be working reasonably well, or at least memcheck and addrcheck are, and people have been asking for it, so here it is. Paul. |
|
From: Tom H. <th...@cy...> - 2004-08-28 03:06:33
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-28 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow badfree-2trace: valgrind --num-callers=2 -q ./badfree badfree: valgrind -q ./badfree badjump: valgrind ./badjump badloop: valgrind -q ./badloop badrw: valgrind -q ./badrw brk: valgrind ./brk brk2: valgrind ./brk2 buflen_check: valgrind -q ./buflen_check clientperm: valgrind -q ./clientperm custom_alloc: valgrind -q ./custom_alloc doublefree: valgrind -q ./doublefree error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw Could not read `fprw.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-28 02:56:45
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-28 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-08-28 02:25:12
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-28 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-28 02:19:56
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-28 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-28 02:13:17
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-28 03:10:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-28 02:08:24
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-08-28 03:05:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |
|
From: Paul M. <pa...@sa...> - 2004-08-28 01:09:43
|
Bob Friesenhahn writes: > Great. However, it seems difficult to me to single-step through lines > of code or instructions. Either two threads of control are necessary, > or it must be possible to switch back and forth between execution > contexts with great precision. I think that breakpoints would need to > be implemented via signals. Why? In valgrind, we *are* the cpu. :) Doing this would mean some changes to the scheduler, but not massive changes. I would think that V would have a socket open to gdb. We would drop the number of BBs that get executed in a bunch from 50000 to say 1000 or less. We would put a poll or select call in the scheduler to check for stuff from gdb, and if there is stuff, we call the gdbstub code. That can read/write memory and cpu registers by itself just fine, and if it wants to suspend execution for a while, it just does a blocking read on the socket. If it wants to write a breakpoint, it writes it, and calls a routine from vg_transtab.c to invalidate any translation of the code where the breakpoint is set. (Yes, this is slow, but we're debugging, so it doesn't matter - and if it does, I have a scheme that I use on PPC that makes invalidating translations much faster.) If it wants to send a signal it calls the routines we already have for delivering a signal on simulated cpu. The remaining thing is single-stepping. Here I think the thing is for the gdbstub routine to return a code to the scheduler indicating single-stepping, after having invalidated the translation (if any) for the current eip. That sets a 'single-stepping' flag, and on the next call to VG_(translate) we pass a parameter (a new parameter) indicating that we want it to translate at most one instruction. We execute that and then call the gdbstub again. We probably also need a new return code from run_thread_for_a_while to indicate that we have hit a breakpoint instruction. That should just about do it. For extra marks, we could subsequently implement "hardware" instruction and data address breakpoints. :) Paul. |