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
(44) |
2
(9) |
3
(30) |
4
(28) |
5
(42) |
6
(14) |
7
(10) |
|
8
(7) |
9
(8) |
10
(6) |
11
(15) |
12
(13) |
13
(14) |
14
(23) |
|
15
(17) |
16
(10) |
17
(82) |
18
(14) |
19
(21) |
20
(14) |
21
(21) |
|
22
(7) |
23
(13) |
24
(16) |
25
(11) |
26
(11) |
27
(6) |
28
(7) |
|
29
(8) |
30
(13) |
31
(8) |
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2006-10-15 22:34:05
|
On Sun, 15 Oct 2006, Julian Seward wrote: >> Hmm, there isn't any reason why a tool should call err_missing_prog or >> err_config_error... I think those two should stay in m_main.c. I see the >> similarity between the three functions, perhaps that should be factored out >> into another function. > > Hmm, that's a good point. Hadn't noticed that before. Alternatively > err_missing_prog and err_config_error could be moved from the tool .h > to the core .h -- what say you to that? That's better because it's not tool-visible. But they're still not used outside of m_main.c, so there's no need to make them visible outside that module. Nick |
|
From: <js...@ac...> - 2006-10-15 14:07:30
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-10-15 09:00:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 214 tests, 10 stderr failures, 8 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/cmdline2 (stdout) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 214 tests, 10 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/jm-int (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 15 09:11:28 2006 --- new.short Sun Oct 15 09:22:57 2006 *************** *** 8,10 **** ! == 214 tests, 10 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) --- 8,10 ---- ! == 214 tests, 10 stderr failures, 8 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) *************** *** 15,16 **** --- 15,17 ---- memcheck/tests/xml1 (stderr) + none/tests/cmdline2 (stdout) none/tests/faultstatus (stderr) |
|
From: <sv...@va...> - 2006-10-15 13:47:46
|
Author: sewardj
Date: 2006-10-15 14:47:43 +0100 (Sun, 15 Oct 2006)
New Revision: 6238
Log:
Minor comment mods.
Modified:
trunk/include/pub_tool_tooliface.h
Modified: trunk/include/pub_tool_tooliface.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/pub_tool_tooliface.h 2006-10-15 13:46:18 UTC (rev 6237)
+++ trunk/include/pub_tool_tooliface.h 2006-10-15 13:47:43 UTC (rev 6238)
@@ -191,7 +191,7 @@
don't match.
=20
- This block is known to be the entry point of a wrapper of some
- function F. In this case the wrapper contains code to write
+ function F. In this case the preamble contains code to write
the address of the original F (the fn being wrapped) into a
'hidden' guest state register _NRADDR. The wrapper can later
read this register using a client request and make a
@@ -199,10 +199,10 @@
magic macro.
=20
- For platforms that use the AIX ABI (including ppc64-linux), it
- is necessary to have a preamble even for replacement
- functions, because it is necessary to switch the R2 register
- (constant-pool pointer) to a different value when swizzling
- the program counter.
+ is necessary to have a preamble even for replacement functions
+ (not just for wrappers), because it is necessary to switch the
+ R2 register (constant-pool pointer) to a different value when
+ swizzling the program counter.
=20
Hence the preamble pushes both R2 and LR (the return address)
on a small 16-entry stack in the guest state and sets R2 to an
|
|
From: <sv...@va...> - 2006-10-15 13:46:22
|
Author: sewardj
Date: 2006-10-15 14:46:18 +0100 (Sun, 15 Oct 2006)
New Revision: 6237
Log:
Add further comments about the tool instrument function.
Modified:
trunk/include/pub_tool_tooliface.h
Modified: trunk/include/pub_tool_tooliface.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/pub_tool_tooliface.h 2006-10-15 12:48:18 UTC (rev 6236)
+++ trunk/include/pub_tool_tooliface.h 2006-10-15 13:46:18 UTC (rev 6237)
@@ -157,6 +157,76 @@
// by either Ity_I32 or Ity_I64. So far we have never built a
// cross-architecture Valgrind so they should always be the same.
//
+ /* --- Further comments about the IR that your --- */
+ /* --- instrumentation function will receive. --- */
+ /*
+ In the incoming IRBB, the IR for each instruction begins with an
+ IRStmt_IMark, which states the address and length of the
+ instruction from which this IR came. This makes it easy for
+ profiling-style tools to know precisely which guest code
+ addresses are being executed.
+
+ However, before the first IRStmt_IMark, there may be other IR
+ statements -- a preamble. In most cases this preamble is empty,
+ but when it isn't, what it contains is some supporting IR that
+ the JIT uses to ensure control flow works correctly. This
+ preamble does not modify any architecturally defined guest state
+ (registers or memory) and so does not contain anything that will
+ be of interest to your tool.
+
+ You should therefore=20
+
+ (1) copy any IR preceding the first IMark verbatim to the start
+ of the output IRBB.
+
+ (2) not try to instrument it or modify it in any way.
+
+ For the record, stuff that may be in the preamble at
+ present is:
+
+ - A self-modifying-code check has been requested for this block.
+ The preamble will contain instructions to checksum the block,
+ compare against the expected value, and exit the dispatcher
+ requesting a discard (hence forcing a retranslation) if they
+ don't match.
+
+ - This block is known to be the entry point of a wrapper of some
+ function F. In this case the wrapper contains code to write
+ the address of the original F (the fn being wrapped) into a
+ 'hidden' guest state register _NRADDR. The wrapper can later
+ read this register using a client request and make a
+ non-redirected call to it using another client-request-like
+ magic macro.
+
+ - For platforms that use the AIX ABI (including ppc64-linux), it
+ is necessary to have a preamble even for replacement
+ functions, because it is necessary to switch the R2 register
+ (constant-pool pointer) to a different value when swizzling
+ the program counter.
+
+ Hence the preamble pushes both R2 and LR (the return address)
+ on a small 16-entry stack in the guest state and sets R2 to an
+ appropriate value for the wrapper/replacement fn. LR is then
+ set so that the wrapper/replacement fn returns to a magic IR
+ stub which restores R2 and LR and returns.
+
+ It's all hugely ugly and fragile. And it places a stringent
+ requirement on m_debuginfo to find out the correct R2 (toc
+ pointer) value for the wrapper/replacement function. So much
+ so that m_redir will refuse to honour a redirect-to-me request
+ if it cannot find (by asking m_debuginfo) a plausible R2 value
+ for 'me'.
+
+ Because this mechanism maintains a shadow stack of (R2,LR)
+ pairs in the guest state, it will fail if the
+ wrapper/redirection function, or anything it calls, longjumps
+ out past the wrapper, because then the magic return stub will
+ not be run and so the shadow stack will not be popped. So it
+ will quickly fill up. Fortunately none of this applies to
+ {x86,amd64,ppc32}-linux; on those platforms, wrappers can
+ longjump and recurse arbitrarily and everything should work
+ fine.
+ */
IRBB*(*instrument)(VgCallbackClosure* closure,=20
IRBB* bb_in,=20
VexGuestLayout* layout,=20
|
|
From: <sv...@va...> - 2006-10-15 12:48:20
|
Author: sewardj
Date: 2006-10-15 13:48:18 +0100 (Sun, 15 Oct 2006)
New Revision: 6236
Log:
Add proper comments explaining the args for the tool instrumenation
function.
Modified:
trunk/include/pub_tool_tooliface.h
Modified: trunk/include/pub_tool_tooliface.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/pub_tool_tooliface.h 2006-10-15 12:47:37 UTC (rev 6235)
+++ trunk/include/pub_tool_tooliface.h 2006-10-15 12:48:18 UTC (rev 6236)
@@ -74,7 +74,7 @@
/* Basic tool functions */
=20
/* The tool_instrument function is passed as a callback to
- LibVEX_Translate. VgInstrumentClosure carries additional info
+ LibVEX_Translate. VgCallbackClosure carries additional info
which the instrumenter might like to know, but which is opaque to
Vex.
*/
@@ -93,14 +93,76 @@
=20
// Instrument a basic block. Must be a true function, ie. the same
// input always results in the same output, because basic blocks
- // can be retranslated. Unless you're doing something really
- // strange... Note that orig_addr_noredir is not necessarily the
- // same as the address of the first instruction in the IR, due to
- // function redirection.
- IRBB*(*instrument)(VgCallbackClosure*,=20
- IRBB* bb_in,=20
- VexGuestLayout*, VexGuestExtents*,=20
- IRType gWordTy, IRType hWordTy),
+ // can be retranslated, unless you're doing something really
+ // strange. Anyway, the arguments. Mostly they are straightforward
+ // except for the distinction between redirected and non-redirected
+ // guest code addresses, which is important to understand.
+ //
+ // VgCallBackClosure* closure contains extra arguments passed
+ // from Valgrind to the instrumenter, which Vex doesn't know about.
+ // You are free to look inside this structure.
+ //
+ // * closure->tid is the ThreadId of the thread requesting the
+ // translation. Not sure why this is here; perhaps callgrind
+ // uses it.
+ //
+ // * closure->nraddr is the non-redirected guest address of the
+ // start of the translation. In other words, the translation is
+ // being constructed because the guest program jumped to=20
+ // closure->nraddr but no translation of it was found.
+ //
+ // * closure->readdr is the redirected guest address, from which
+ // the translation was really made.
+ //
+ // To clarify this, consider what happens when, in Memcheck, the
+ // first call to malloc() happens. The guest program will be
+ // trying to jump to malloc() in libc; hence ->nraddr will contain
+ // that address. However, Memcheck intercepts and replaces
+ // malloc, hence ->readdr will be the address of Memcheck's
+ // malloc replacement in
+ // coregrind/m_replacemalloc/vg_replacemalloc.c. It follows
+ // that the first IMark in the translation will be labelled as
+ // from ->readdr rather than ->nraddr.
+ //
+ // Since most functions are not redirected, the majority of the
+ // time ->nraddr will be the same as ->readdr. However, you
+ // cannot assume this: if your tool has metadata associated
+ // with code addresses it will get into deep trouble if it does
+ // make this assumption.
+ //
+ // IRBB* bb_in is the incoming bb to be instrumented, in flat IR
+ // form.
+ //
+ // VexGuestLayout* layout contains limited info on the layout of
+ // the guest state: where the stack pointer and program counter
+ // are, and which fields should be regarded as 'always defined'.
+ // Memcheck uses this.
+ //
+ // VexGuestExtents* vge points to a structure which states the
+ // precise byte ranges of original code from which this translation
+ // was made (there may be up to three different ranges involved).
+ // Note again that these are the real addresses from which the code
+ // came. And so it should be the case that closure->readdr is the
+ // same as vge->base[0]; indeed Cachegrind contains this assertion.
+ //
+ // Tools which associate shadow data with code addresses
+ // (cachegrind, callgrind) need to be particularly clear about
+ // whether they are making the association with redirected or
+ // non-redirected code addresses. Both approaches are viable
+ // but you do need to understand what's going on. See comments
+ // below on discard_basic_block_info().
+ //
+ // IRType gWordTy and IRType hWordTy contain the types of native
+ // words on the guest (simulated) and host (real) CPUs. They will
+ // by either Ity_I32 or Ity_I64. So far we have never built a
+ // cross-architecture Valgrind so they should always be the same.
+ //
+ IRBB*(*instrument)(VgCallbackClosure* closure,=20
+ IRBB* bb_in,=20
+ VexGuestLayout* layout,=20
+ VexGuestExtents* vge,=20
+ IRType gWordTy,=20
+ IRType hWordTy),
=20
// Finish up, print out any results, etc. `exitcode' is program's ex=
it
// code. The shadow can be found with VG_(get_exit_status_shadow)().
@@ -215,9 +277,10 @@
// - If info is being stored at a per-translation level, use orig_add=
r
// to identify which translation is being discarded. Each translat=
ion
// will be discarded exactly once.
- // This orig_addr will match the orig_addr which was passed to
- // to instrument() when this translation was made. Note that orig_=
addr
- // won't necessarily be the same as the first address in "extents".
+ // This orig_addr will match the closure->nraddr which was passed t=
o
+ // to instrument() (see extensive comments above) when this=20
+ // translation was made. Note that orig_addr won't necessarily be=20
+ // the same as the first address in "extents".
// - If info is being stored at a per-instruction level, you can get
// the address range(s) being discarded by stepping through "extent=
s".
// Note that any single instruction may belong to more than one
|
|
From: <sv...@va...> - 2006-10-15 12:47:40
|
Author: sewardj
Date: 2006-10-15 13:47:37 +0100 (Sun, 15 Oct 2006)
New Revision: 6235
Log:
wibble
Modified:
trunk/memcheck/mc_translate.c
Modified: trunk/memcheck/mc_translate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/mc_translate.c 2006-10-15 01:26:40 UTC (rev 6234)
+++ trunk/memcheck/mc_translate.c 2006-10-15 12:47:37 UTC (rev 6235)
@@ -90,6 +90,7 @@
/* READONLY: the guest layout. This indicates which parts of
the guest state should be regarded as 'always defined'. */
VexGuestLayout* layout;
+
/* READONLY: the host word type. Needed for constructing
arguments of type 'HWord' to be passed to helper functions.
Ity_I32 or Ity_I64 only. */
|
|
From: Julian S. <js...@ac...> - 2006-10-15 11:59:14
|
> > +/* Call this if a recognised option was bad for some reason. Note: > > + don't use it just because an option was unrecognised -- return > > + 'False' from VG_(tdict).tool_process_cmd_line_option) to indicate > > + that. This function prints an error message, then shuts down the > > + entire system. */ > > +extern void VG_(err_bad_option) ( Char* opt ); > > + > > +/* Similarly - complain that the executable is missing, then stop. */ > > +extern void VG_(err_missing_prog) ( void ); > > + > > +/* Similarly - complain about some config error. */ > > +extern void VG_(err_config_error) ( Char* msg ); > > Hmm, there isn't any reason why a tool should call err_missing_prog or > err_config_error... I think those two should stay in m_main.c. I see the > similarity between the three functions, perhaps that should be factored out > into another function. Hmm, that's a good point. Hadn't noticed that before. Alternatively err_missing_prog and err_config_error could be moved from the tool .h to the core .h -- what say you to that? J |
|
From: Nicholas N. <nj...@cs...> - 2006-10-15 11:08:23
|
On Sun, 15 Oct 2006 sv...@va... wrote: > Modified: trunk/include/pub_tool_options.h > =================================================================== > --- trunk/include/pub_tool_options.h 2006-10-15 00:07:24 UTC (rev 6232) > +++ trunk/include/pub_tool_options.h 2006-10-15 01:25:13 UTC (rev 6233) > @@ -75,15 +75,24 @@ > XML output, in between <usercomment> tags. */ > extern HChar* VG_(clo_xml_user_comment); > > -/* Call this if a recognised option was bad for some reason. > - Note: don't use it just because an option was unrecognised -- return 'False' > - from VG_(tdict).tool_process_cmd_line_option) to indicate that. */ > -extern void VG_(bad_option) ( Char* opt ); > - > /* Vex iropt control. Tool-visible so tools can make Vex optimise > less aggressively if that is needed (callgrind needs this). */ > extern VexControl VG_(clo_vex_control); > > +/* Call this if a recognised option was bad for some reason. Note: > + don't use it just because an option was unrecognised -- return > + 'False' from VG_(tdict).tool_process_cmd_line_option) to indicate > + that. This function prints an error message, then shuts down the > + entire system. */ > +extern void VG_(err_bad_option) ( Char* opt ); > + > +/* Similarly - complain that the executable is missing, then stop. */ > +extern void VG_(err_missing_prog) ( void ); > + > +/* Similarly - complain about some config error. */ > +extern void VG_(err_config_error) ( Char* msg ); Hmm, there isn't any reason why a tool should call err_missing_prog or err_config_error... I think those two should stay in m_main.c. I see the similarity between the three functions, perhaps that should be factored out into another function. Nick |
|
From: Tom H. <to...@co...> - 2006-10-15 02:45:41
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-10-15 03:30:04 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 246 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline2 (stdout) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 246 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 15 03:38:03 2006 --- new.short Sun Oct 15 03:45:34 2006 *************** *** 8,10 **** ! == 246 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 246 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 12,13 **** --- 12,14 ---- memcheck/tests/x86/scalar (stderr) + none/tests/cmdline2 (stdout) none/tests/mremap (stderr) |
|
From: Tom H. <th...@cy...> - 2006-10-15 02:25:42
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-10-15 03:10:03 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 274 tests, 20 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/cmdline2 (stdout) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_creat (stderr) none/tests/fdleak_dup (stderr) none/tests/fdleak_dup2 (stderr) none/tests/fdleak_fcntl (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/fdleak_open (stderr) none/tests/fdleak_pipe (stderr) none/tests/fdleak_socketpair (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/rlimit_nofile (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 274 tests, 20 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_creat (stderr) none/tests/fdleak_dup (stderr) none/tests/fdleak_dup2 (stderr) none/tests/fdleak_fcntl (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/fdleak_open (stderr) none/tests/fdleak_pipe (stderr) none/tests/fdleak_socketpair (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/rlimit_nofile (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 15 03:17:49 2006 --- new.short Sun Oct 15 03:25:32 2006 *************** *** 8,10 **** ! == 274 tests, 20 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) --- 8,10 ---- ! == 274 tests, 20 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) *************** *** 18,19 **** --- 18,20 ---- memcheck/tests/xml1 (stderr) + none/tests/cmdline2 (stdout) none/tests/fdleak_cmsg (stderr) |
|
From: Tom H. <th...@cy...> - 2006-10-15 02:24:47
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-10-15 03:15:01 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccCVU0NT.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccCVU0NT.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.26725/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.26725/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.26725/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.26725/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.26725/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccOTa5hm.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccOTa5hm.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.26725/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.26725/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.26725/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.26725/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.26725/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 15 03:19:48 2006 --- new.short Sun Oct 15 03:24:33 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccOTa5hm.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccOTa5hm.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccCVU0NT.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccCVU0NT.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-10-15 02:20:16
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-10-15 03:05:06 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 274 tests, 11 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/cmdline2 (stdout) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 274 tests, 12 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 15 03:13:00 2006 --- new.short Sun Oct 15 03:20:04 2006 *************** *** 8,10 **** ! == 274 tests, 12 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) --- 8,10 ---- ! == 274 tests, 11 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) *************** *** 15,19 **** memcheck/tests/leak-pool-5 (stderr) - memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) - memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) --- 15,17 ---- *************** *** 21,22 **** --- 19,21 ---- memcheck/tests/x86/scalar_supp (stderr) + none/tests/cmdline2 (stdout) none/tests/mremap (stderr) |
|
From: Tom H. <th...@cy...> - 2006-10-15 02:14:04
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-10-15 03:00:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 276 tests, 12 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/cmdline2 (stdout) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 276 tests, 12 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Oct 15 03:06:55 2006 --- new.short Sun Oct 15 03:13:44 2006 *************** *** 8,10 **** ! == 276 tests, 12 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) --- 8,10 ---- ! == 276 tests, 12 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-pool-0 (stderr) *************** *** 19,20 **** --- 19,21 ---- memcheck/tests/x86/scalar_supp (stderr) + none/tests/cmdline2 (stdout) none/tests/fdleak_fcntl (stderr) |
|
From: <sv...@va...> - 2006-10-15 01:26:44
|
Author: sewardj Date: 2006-10-15 02:26:40 +0100 (Sun, 15 Oct 2006) New Revision: 6234 Log: Move code that creates the initial Linux memory image (stack, env, etc) from m_main into m_initimg. Added: trunk/coregrind/m_initimg/initimg-linux.c trunk/coregrind/pub_core_initimg.h Modified: trunk/coregrind/Makefile.am trunk/coregrind/m_main.c [... diff too large to include ...] |
|
From: <sv...@va...> - 2006-10-15 01:25:20
|
Author: sewardj
Date: 2006-10-15 02:25:13 +0100 (Sun, 15 Oct 2006)
New Revision: 6233
Log:
Move functions which deal with bad command line options from m_main
into m_options.
Modified:
trunk/cachegrind/cg_main.c
trunk/callgrind/sim.c
trunk/coregrind/m_options.c
trunk/coregrind/m_replacemalloc/replacemalloc_core.c
trunk/include/pub_tool_options.h
trunk/massif/ms_main.c
Modified: trunk/cachegrind/cg_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/cachegrind/cg_main.c 2006-10-15 00:07:24 UTC (rev 6232)
+++ trunk/cachegrind/cg_main.c 2006-10-15 01:25:13 UTC (rev 6233)
@@ -1288,7 +1288,7 @@
return;
=20
bad:
- VG_(bad_option)(opt);
+ VG_(err_bad_option)(opt);
}
=20
static Bool cg_process_cmd_line_option(Char* arg)
Modified: trunk/callgrind/sim.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/callgrind/sim.c 2006-10-15 00:07:24 UTC (rev 6232)
+++ trunk/callgrind/sim.c 2006-10-15 01:25:13 UTC (rev 6233)
@@ -1637,7 +1637,7 @@
return;
=20
bad:
- VG_(bad_option)(orig_opt);
+ VG_(err_bad_option)(orig_opt);
}
=20
/* Check for command line option for cache configuration.
Modified: trunk/coregrind/m_options.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_options.c 2006-10-15 00:07:24 UTC (rev 6232)
+++ trunk/coregrind/m_options.c 2006-10-15 01:25:13 UTC (rev 6233)
@@ -31,6 +31,8 @@
=20
#include "pub_core_basics.h"
#include "pub_core_options.h"
+#include "pub_core_libcassert.h"
+#include "pub_core_libcprint.h"
=20
// See pub_{core,tool}_options.h for explanations of all these.
=20
@@ -79,6 +81,41 @@
HChar* VG_(clo_kernel_variant) =3D NULL;
=20
=20
+/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
+/*=3D=3D=3D Command line errors =
=3D=3D=3D*/
+/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*/
+
+static void revert_to_stderr ( void )
+{
+ vg_assert( !VG_(logging_to_socket) );
+ VG_(clo_log_fd) =3D 2; /* stderr */
+}
+
+void VG_(err_bad_option) ( Char* opt )
+{
+ revert_to_stderr();
+ VG_(printf)("valgrind: Bad option '%s'; aborting.\n", opt);
+ VG_(printf)("valgrind: Use --help for more information.\n");
+ VG_(exit)(1);
+}
+
+void VG_(err_missing_prog) ( void )
+{
+ revert_to_stderr();
+ VG_(printf)("valgrind: no program specified\n");
+ VG_(printf)("valgrind: Use --help for more information.\n");
+ VG_(exit)(1);
+}
+
+void VG_(err_config_error) ( Char* msg )
+{
+ revert_to_stderr();
+ VG_(printf)("valgrind: Startup or configuration error:\n %s\n", msg=
);
+ VG_(printf)("valgrind: Unable to start up properly. Giving up.\n");
+ VG_(exit)(1);
+}
+
+
/*--------------------------------------------------------------------*/
/*--- end m_options.c ---*/
/*--------------------------------------------------------------------*/
Modified: trunk/coregrind/m_replacemalloc/replacemalloc_core.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_replacemalloc/replacemalloc_core.c 2006-10-15 00:07=
:24 UTC (rev 6232)
+++ trunk/coregrind/m_replacemalloc/replacemalloc_core.c 2006-10-15 01:25=
:13 UTC (rev 6233)
@@ -63,7 +63,7 @@
VG_(message)(Vg_UserMsg,=20
"Invalid --alignment=3D setting. "
"Should be a power of 2, >=3D %d, <=3D 4096.", VG_MIN_MALLOC=
_SZB);
- VG_(bad_option)("--alignment");
+ VG_(err_bad_option)("--alignment");
}
}
=20
Modified: trunk/include/pub_tool_options.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/pub_tool_options.h 2006-10-15 00:07:24 UTC (rev 6232)
+++ trunk/include/pub_tool_options.h 2006-10-15 01:25:13 UTC (rev 6233)
@@ -75,15 +75,24 @@
XML output, in between <usercomment> tags. */
extern HChar* VG_(clo_xml_user_comment);
=20
-/* Call this if a recognised option was bad for some reason.
- Note: don't use it just because an option was unrecognised -- return =
'False'
- from VG_(tdict).tool_process_cmd_line_option) to indicate that. */
-extern void VG_(bad_option) ( Char* opt );
-
/* Vex iropt control. Tool-visible so tools can make Vex optimise
less aggressively if that is needed (callgrind needs this). */
extern VexControl VG_(clo_vex_control);
=20
+/* Call this if a recognised option was bad for some reason. Note:
+ don't use it just because an option was unrecognised -- return
+ 'False' from VG_(tdict).tool_process_cmd_line_option) to indicate
+ that. This function prints an error message, then shuts down the
+ entire system. */
+extern void VG_(err_bad_option) ( Char* opt );
+
+/* Similarly - complain that the executable is missing, then stop. */
+extern void VG_(err_missing_prog) ( void );
+
+/* Similarly - complain about some config error. */
+extern void VG_(err_config_error) ( Char* msg );
+
+
#endif // __PUB_TOOL_OPTIONS_H
=20
/*--------------------------------------------------------------------*/
Modified: trunk/massif/ms_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/massif/ms_main.c 2006-10-15 00:07:24 UTC (rev 6232)
+++ trunk/massif/ms_main.c 2006-10-15 01:25:13 UTC (rev 6233)
@@ -298,7 +298,7 @@
n_alloc_fns++;
if (n_alloc_fns >=3D MAX_ALLOC_FNS) {
VG_(printf)("Too many alloc functions specified, sorry");
- VG_(bad_option)(arg);
+ VG_(err_bad_option)(arg);
}
}
=20
|
|
From: James Courtier-D. <Ja...@su...> - 2006-10-15 00:16:11
|
Nicholas Nethercote wrote: > On Sat, 14 Oct 2006, James Courtier-Dutton wrote: > >> Are there any tool available to tell me if a particular executable or >> lib can contain self modifying code. I.e. Executes instructions in a >> page that does not have Read/Execute set, but instead has >> Read/Write/Execute set. >> >> I understand that valgrind can work with self modifying code so that is >> why I ask here. > > It's possible to have code executed from a RWX page that is not > self-modifying. I know it is possible, but if the code executed from a RWX page is not self-modifying, why would one not set it to R-X instead? > >> I want to try to scan an entire system and highlight all executables and >> libs that might have self modifying code in them. >> >> Obviously, things like java jit might have self modifying code, but I >> want to detect all such programs. > > I think you're confusing self-modifying code with dynamically generated > code. How does dynamically generated code work? Is it possible for an application to change the page type of one of it's pages while running. I.e. start with a data page, fill is with code, and then change the page to +X. > > There are no existing tools to do this, but it would be straightforward > to modify Valgrind's core to detect this. But it sounds like you want > something that can detect this statically, which Valgrind cannot do. > > Nick I don't necessarily want to detect code actually changing. I want to be able to detect rwx pages. The only x pages I want to see are r-x pages. This is in part to aid security. James |
|
From: <sv...@va...> - 2006-10-15 00:07:33
|
Author: sewardj Date: 2006-10-15 01:07:24 +0100 (Sun, 15 Oct 2006) New Revision: 6232 Log: New module, for creating the initial process image -- to contain various bits currently in m_main.c. Added: trunk/coregrind/m_initimg/ |