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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Josef W. <Jos...@gm...> - 2003-12-18 20:12:22
|
On Thursday 18 December 2003 19:17, Josef Weidendorfer wrote:
> Where should I allocate space for this flag?
> Or better: How to get rid of the permission check, i.e. the "%fs:" segment?
Followup:
Of course, with --pointercheck=no, I can avoid the %fs prefix. But in this
case, this should be avoided even with --pointercheck=yes, as this is a
STORE instruction generated by the tool.
As LOAD/STORE always does a bound check, there are 3 possibilities:
* I add an extended UCode for this,
* We add LOAD/STORE variants that explicitly do no bound checks, which
can be used by tools.
* Add a flag to LOAD/STORE if a boundcheck should explicitly avoided.
I got a crash when I use valgrind with --pointercheck=no. This has nothing to
do with my tool.
E.g. a valgrind --tool=none --pointercheck=no gives me:
================================================
==12818== For more details, rerun with: -v
==12818==
valgrind: vg_scheduler.c:1172 (vgPlain_scheduler): Assertion `done_this_time
>= 0' failed.
==12818== at 0xB8029A61: vgPlain_skin_assert_fail (vg_mylibc.c:1161)
==12818== by 0xB8029A60: assert_fail (vg_mylibc.c:1157)
==12818== by 0xB8029A9E: vgPlain_core_assert_fail (vg_mylibc.c:1168)
==12818== by 0xB800EECC: vgPlain_scheduler (vg_scheduler.c:1216)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==12818== at 0x81000C10: (within /lib/ld-2.3.2.so)
==================================================
That's before the first BB is executed. Looking at vg_scheduler.c:
1171 done_this_time = (Int)dispatch_ctr_SAVED - (Int)VG_(dispatch_ctr) -1;
1172 vg_assert(done_this_time >= 0);
done_this_time should be the number of BB executed in the inner loop, isn't
it? But why the "-1" ? Somehow with "--pointercheck=no", done_this_time can
be -1 the first time, and thus the assertion failed.
So I simply removed the "-1".
Now I get another SEGFAULT crash. Using gdb, I found out that in vg_dispatch.S
there is a check for clo_checkpointer,assuming a integer type, but Bool is a
"unsigned char". Change the 2 checks, e.g. the first check to
movb VG_(clo_pointercheck), %al
testb %al,%al
, and valgrind runs fine with --pointercheck=no.
Even my skin runs fine now.
Cheers,
Josef
|
|
From: Josef W. <Jos...@gm...> - 2003-12-18 18:17:30
|
On Thursday 18 December 2003 02:06, Jeremy Fitzhardinge wrote:
> Eh, are you saying that the --trace-codegen=10001 output only starts
> after 0x81000D10? I can't see any way in which can not print for early
I found the culprit. Tracegen output started at BB 1, not at BB 0. Patch:
==================================================
--- vg_translate.c 18 Dec 2003 09:06:08 -0000 1.64
+++ vg_translate.c 18 Dec 2003 17:29:59 -0000
@@ -2386,7 +2386,7 @@ void VG_(translate) ( /*IN*/ ThreadId t
notrace_until_limit to be the number of translations to be made
before --trace-codegen= style printing takes effect. */
notrace_until_done
- = VG_(overall_in_count) > notrace_until_limit;
+ = VG_(overall_in_count) >= notrace_until_limit;
seg = VG_(find_segment)(orig_addr);
====================================================
I attached the output of "valgrind --skin=calltree --trace-codegen=10101 ls".
Using the debugger, I found out the place of the SEGFAULT at 0xb874d054,
in the translation of the first basic block. Disassembled with GDB:
...
Dump of assembler code from 0xb874d040 to 0xb874d060:
0xb874d040: mov $0x81000c17,%esi
0xb874d045: mov %edx,%edi
0xb874d047: mov %esi,%fs:(%edx)
0xb874d04a: mov $0xb018eb0c,%eax
0xb874d04f: mov $0x1,%ebx
0xb874d054: mov %ebx,%fs:(%eax)
0xb874d057: mov $0x68,%eax
0xb874d05c: mov %edi,%edx
0xb874d05e: call *0x30(%ebp)
...
Address 0xb874d054 corresponds to Offset 72 in the translated version (from
the attachment):
14: MOVL $0x1, %ebx [ab---D]
67: BB 01 00 00 00
movl $0x1, %ebx
15: STL %ebx, (%eax) [-----D]
72: 64 89 18
movl %ebx, (%eax)
Here, value 1 is a flag I write into a global variable of my skin/tool.
Obviously, this goes wrong as the client has no right to write into valgrind's
space (?). The flag is to be used in a helper called by the translation of the
next basic block.
Where should I allocate space for this flag?
Or better: How to get rid of the permission check, i.e. the "%fs:" segment?
Josef
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 18:02:33
|
On Thu, 2003-12-18 at 09:09, Tom Hughes wrote: > Attached is a patch to fix this. Oops. Thanks. J |
|
From: Tom H. <th...@cy...> - 2003-12-18 17:10:32
|
In message <1071540160.20064.65.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> I've been testing this pretty solidly for a while, so I think it should
> work OK. No doubt you'll find some problems, but that's why I'm
> checking it in (and why we did the 2.1.0 release *before* checking it in
> - so that there's something semi-stable for people to play with).
I've found another problem - if you fork and exec then it removes
the vg_inject.so entry from LD_PRELOAD but not any vgpreload_xxx.so
entry that the current tool may have added, so if you're using
memcheck you wind up with a very oddly broken malloc in the child
process ;-)
Attached is a patch to fix this.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-12-18 10:05:10
|
In message <107...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Thu, 2003-12-18 at 00:24, Tom Hughes wrote:
>> It gives the kernel a pointer to a pid_t which in which it should
>> store the current thread's tid whenever it feels like it. In this
>> case ld.so was actually passing NULL as the argument so it was in
>> fact turning off this functionality.
>
> So we can just ignore the syscall for now?
I suspect so, because it seemed to work even though it printed a
warning about the unimplemented system call.
>> No. It was looking at the symbol tables and was managing to map about
>> half the libraries then reporting mmap failed for the rest. As I increased
>> that number it gradually reported fewer and fewer failures.
>
> Hm. I'm a bit confused. Can you look at what's mapped at the time it
> fails?
I'll have a look.
>> At 4 and 5, after stdin/out/err and my valgrind log fd which is 3:
>
> That was actually a bug in your patch to set VG_(max_fds) dynamically -
> it was trying to use VG_(safe_fd) before you'd initialized
> VG_(max_fds). I just checked in a fix.
Ah right. I'd forgotten I had some of my patches applied ;-)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:09:25
|
CVS commit by fitzhardinge: Sigh. Add the test files. A yield.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright] A yield.stderr.exp 1.1 A yield.stdout.exp 1.1 A yield.vgtest 1.1 |
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:06:42
|
CVS commit by fitzhardinge:
Make rep; nop (pause) yield the thread. Based on a patch by Tom Hughes;
I added a test case and cleaned up vg_dispatch.S while I was about it.
CCMAIL: 695...@bu...
M +1 -0 coregrind/vg_constants.h 1.14
M +2 -21 coregrind/vg_dispatch.S 1.13
M +3 -0 coregrind/vg_from_ucode.c 1.69
M +10 -0 coregrind/vg_scheduler.c 1.134
M +5 -1 coregrind/vg_to_ucode.c 1.116
M +1 -0 coregrind/vg_translate.c 1.64
M +2 -1 include/vg_skin.h.base 1.4
M +5 -2 none/tests/Makefile.am 1.17
--- valgrind/coregrind/vg_constants.h #1.13:1.14
@@ -49,4 +49,5 @@
#define VG_TRC_EBP_JMP_SYSCALL 19 /* EBP and TRC */
#define VG_TRC_EBP_JMP_CLIENTREQ 23 /* EBP and TRC */
+#define VG_TRC_EBP_JMP_YIELD 27 /* EBP and TRC */
#define VG_TRC_INNER_FASTMISS 31 /* TRC only; means fast-cache miss. */
--- valgrind/coregrind/vg_dispatch.S #1.12:1.13
@@ -170,30 +170,11 @@
dispatch_exceptional:
/* this is jumped to only, not fallen-through from above */
- cmpl $VG_TRC_EBP_JMP_SYSCALL, %ebp
- jz dispatch_syscall
- cmpl $VG_TRC_EBP_JMP_CLIENTREQ, %ebp
- jz dispatch_clientreq
cmpl $VG_TRC_INNER_COUNTERZERO, %ebp
jz counter_is_zero
-
- /* ebp has an invalid value ... crap out. */
- pushl $panic_msg_ebp
- call VG_(core_panic)
- /* (never returns) */
-dispatch_syscall:
- /* save %eax in %EIP and defer to sched */
- movl $VG_(baseBlock), %ebp
- movl VGOFF_(m_eip), %esi
- movl %eax, (%ebp, %esi, 4)
- movl $VG_TRC_EBP_JMP_SYSCALL, %eax
- jmp run_innerloop_exit
-
-dispatch_clientreq:
/* save %eax in %EIP and defer to sched */
- movl $VG_(baseBlock), %ebp
movl VGOFF_(m_eip), %esi
- movl %eax, (%ebp, %esi, 4)
- movl $VG_TRC_EBP_JMP_CLIENTREQ, %eax
+ movl %eax, VG_(baseBlock)(,%esi, 4)
+ movl %ebp, %eax
jmp run_innerloop_exit
--- valgrind/coregrind/vg_from_ucode.c #1.68:1.69
@@ -2550,4 +2550,7 @@ static void load_ebp_from_JmpKind ( JmpK
VG_(emit_movv_lit_reg) ( 4, VG_TRC_EBP_JMP_CLIENTREQ, R_EBP );
break;
+ case JmpYield:
+ VG_(emit_movv_lit_reg) ( 4, VG_TRC_EBP_JMP_YIELD, R_EBP );
+ break;
default:
VG_(core_panic)("load_ebp_from_JmpKind");
--- valgrind/coregrind/vg_scheduler.c #1.133:1.134
@@ -248,4 +248,5 @@ Char* name_of_sched_event ( UInt event )
case VG_TRC_EBP_JMP_SYSCALL: return "SYSCALL";
case VG_TRC_EBP_JMP_CLIENTREQ: return "CLIENTREQ";
+ case VG_TRC_EBP_JMP_YIELD: return "YIELD";
case VG_TRC_INNER_COUNTERZERO: return "COUNTERZERO";
case VG_TRC_INNER_FASTMISS: return "FASTMISS";
@@ -1187,4 +1188,13 @@ VgSchedReturnCode VG_(scheduler) ( void
switch (trc) {
+ case VG_TRC_EBP_JMP_YIELD:
+ /* Explicit yield. Let a new thread be scheduled,
+ simply by doing nothing, causing us to arrive back at
+ Phase 1. */
+ if (VG_(bbs_to_go) == 0) {
+ goto debug_stop;
+ }
+ break;
+
case VG_TRC_INNER_COUNTERZERO:
/* Timeslice is out. Let a new thread be scheduled,
--- valgrind/coregrind/vg_to_ucode.c #1.115:1.116
@@ -5556,5 +5556,9 @@ static Addr disInstr ( UCodeBlock* cb, A
if (abyte == 0x90) { /* REP NOP (PAUSE) */
if (dis) VG_(printf)("rep nop (P4 pause)\n");
- /* do nothing; apparently a hint to the P4 re spin-wait loop */
+ uInstr1(cb, JMP, 0, Literal, 0);
+ uLiteral(cb, eip);
+ uCond(cb, CondAlways);
+ LAST_UINSTR(cb).jmpkind = JmpYield;
+ *isEnd = True;
}
else {
--- valgrind/coregrind/vg_translate.c #1.63:1.64
@@ -1134,4 +1134,5 @@ void pp_UInstrWorker ( Int instrNo, UIns
case JmpSyscall: VG_(printf)("-sys"); break;
case JmpClientReq: VG_(printf)("-cli"); break;
+ case JmpYield: VG_(printf)("-yld"); break;
default: break;
}
--- valgrind/include/vg_skin.h.base #1.3:1.4
@@ -877,5 +877,6 @@
JmpRet=2, /* jump due to an x86 ret insn */
JmpSyscall=3, /* do a system call, then jump */
- JmpClientReq=4 /* do a client request, then jump */
+ JmpClientReq=4,/* do a client request, then jump */
+ JmpYield=5 /* do a yield, then jump */
}
JmpKind;
--- valgrind/none/tests/Makefile.am #1.16:1.17
@@ -36,5 +36,6 @@
shortpush.stderr.exp shortpush.vgtest \
shorts.stderr.exp shorts.vgtest \
- smc1.stderr.exp smc1.stdout.exp smc1.vgtest
+ smc1.stderr.exp smc1.stdout.exp smc1.vgtest \
+ yield.stdout.exp yield.vgtest
check_PROGRAMS = \
@@ -44,5 +45,5 @@
rcrl readline1 resolv seg_override sha1_test shortpush shorts smc1 \
pth_blockedsig \
- coolo_sigaction gxx304
+ coolo_sigaction gxx304 yield
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -g -I$(top_srcdir)/include
@@ -73,4 +74,6 @@
shortpush_SOURCES = shortpush.c
shorts_SOURCES = shorts.c
+yield_SOURCES = yield.c
+yield_LDADD = -lpthread
# pthread C ones
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 09:03:40
|
On Thu, 2003-12-18 at 00:24, Tom Hughes wrote: > It gives the kernel a pointer to a pid_t which in which it should > store the current thread's tid whenever it feels like it. In this > case ld.so was actually passing NULL as the argument so it was in > fact turning off this functionality. So we can just ignore the syscall for now? > No. It was looking at the symbol tables and was managing to map about > half the libraries then reporting mmap failed for the rest. As I increased > that number it gradually reported fewer and fewer failures. Hm. I'm a bit confused. Can you look at what's mapped at the time it fails? > >> I noticed that if you track FD leaks then both /usr/bin/valgrind and > >> the client executable are reported as leaks. > > > > That shouldn't be. What fds is it finding them at? > > At 4 and 5, after stdin/out/err and my valgrind log fd which is 3: That was actually a bug in your patch to set VG_(max_fds) dynamically - it was trying to use VG_(safe_fd) before you'd initialized VG_(max_fds). I just checked in a fix. J |
|
From: Tom H. <th...@cy...> - 2003-12-18 08:24:44
|
In message <1071709848.16950.17.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Wed, 2003-12-17 at 03:41, Tom Hughes wrote:
>> With RH9 it was complaining about syscall 258 which is set_tid_address
>> which is called by ld.so early on, so valgrind never used to see it. A
>> patch to add support for this is attached.
>
> What does set_tid_address do again? It might be better to just silently
> fail it with ENOSYS since we're not doing anything useful with that
> stuff yet.
It gives the kernel a pointer to a pid_t which in which it should
store the current thread's tid whenever it feels like it. In this
case ld.so was actually passing NULL as the argument so it was in
fact turning off this functionality.
>> Although simple programs worked, a debug build of one of our main
>> programs failed to mmap many of the shared objects. I managed to work
>> round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little
>> over 300Mb in size. Debug builds of our software are somewhat extreme
>> in their use of shared libraries - this program had about 150 or so
>> and they mostly had level 3 DWARF debugging on.
>
> It should only be trying to map one of those in at once - do you really
> have a 100MByte+ .so file?
No. It was looking at the symbol tables and was managing to map about
half the libraries then reporting mmap failed for the rest. As I increased
that number it gradually reported fewer and fewer failures.
>> I noticed that if you track FD leaks then both /usr/bin/valgrind and
>> the client executable are reported as leaks.
>
> That shouldn't be. What fds is it finding them at?
At 4 and 5, after stdin/out/err and my valgrind log fd which is 3:
==23501== FILE DESCRIPTORS: 6 open at exit.
==23501== Open file descriptor 5: /usr/cqcs/V72X/cqcs/vcq
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 4: /usr/bin/valgrind
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 3: /home/thh/vg.out
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 2: /dev/pts/1
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 1: /dev/pts/1
==23501== <inherited from parent>
==23501==
==23501== Open file descriptor 0: /dev/pts/1
==23501== <inherited from parent>
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 07:23:17
|
CVS commit by fitzhardinge:
Fix a bug in the last VG_(max_fd) change; VG_(safe_fd) doesn't work before
VG_(max_fd) has been set up.
M +6 -6 vg_main.c 1.132
M +2 -0 vg_mylibc.c 1.62
--- valgrind/coregrind/vg_main.c #1.131:1.132
@@ -155,5 +155,5 @@ Int VG_(main_pgrp);
/* Maximum allowed application-visible file descriptor */
-Int VG_(max_fd);
+Int VG_(max_fd) = -1;
/* Words. */
@@ -1404,9 +1404,4 @@ void VG_(main) ( const KickstartParams *
vg_assert(VG_(clstk_end) == VG_(client_end));
- if (kp->vgexecfd != -1)
- VG_(vgexecfd) = VG_(safe_fd)(kp->vgexecfd);
- if (kp->clexecfd != -1)
- VG_(clexecfd) = VG_(safe_fd)(kp->clexecfd);
-
if (0) {
if (VG_(have_ssestate))
@@ -1438,4 +1433,9 @@ void VG_(main) ( const KickstartParams *
VG_(setrlimit)(VKI_RLIMIT_NOFILE, &rl);
+ if (kp->vgexecfd != -1)
+ VG_(vgexecfd) = VG_(safe_fd)(kp->vgexecfd);
+ if (kp->clexecfd != -1)
+ VG_(clexecfd) = VG_(safe_fd)(kp->clexecfd);
+
/* Read /proc/self/maps into a buffer. Must be before:
- SK_(pre_clo_init)(): so that if it calls VG_(malloc)(), any mmap'd
--- valgrind/coregrind/vg_mylibc.c #1.61:1.62
@@ -1204,4 +1204,6 @@ Int VG_(safe_fd)(Int oldfd)
Int newfd;
+ vg_assert(VG_(max_fd) != -1);
+
newfd = VG_(fcntl)(oldfd, VKI_F_DUPFD, VG_(max_fd)+1);
if (newfd != -1)
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 02:39:53
|
CVS commit by fitzhardinge:
Patch from Tom Hughes: set VG_(max_fd) based on the current file
descriptor limit rather than assuming 1024.
M +6 -8 coregrind/vg_include.h 1.161
M +24 -1 coregrind/vg_main.c 1.131
M +13 -2 coregrind/vg_mylibc.c 1.61
M +4 -4 coregrind/vg_syscalls.c 1.70
M +3 -0 include/vg_skin.h.base 1.3
--- valgrind/coregrind/vg_include.h #1.160:1.161
@@ -109,12 +109,7 @@
#define VG_SCHEDULING_QUANTUM 50000
-/* Maximum FD Valgrind can use for its internal file descriptors. */
-#define VG_MAX_SAFE_FD 1024 /* usual ulimit */
-
-/* Maximum allowed application-visible file descriptor. Valgrind's
- internal fds hide above this (starting at VG_MAX_FD+1). This is
- derived from the default fd limit (1024) minus the 2 fds per thread
- and a small number of extra fds. */
-#define VG_MAX_FD (VG_MAX_SAFE_FD - (VG_N_THREADS*2 + 4))
+/* Number of file descriptors that Valgrind tries to reserve for
+ it's own use - two per thread plues a small number of extras. */
+#define VG_N_RESERVED_FDS (VG_N_THREADS*2 + 4)
/* Stack size for a thread. We try and check that they do not go
@@ -183,4 +178,7 @@ extern Int VG_(main_pid);
extern Int VG_(main_pgrp);
+/* Maximum allowed application-visible file descriptor */
+extern Int VG_(max_fd);
+
/* Should we stop collecting errors if too many appear? default: YES */
extern Bool VG_(clo_error_limit);
--- valgrind/coregrind/vg_main.c #1.130:1.131
@@ -154,4 +154,7 @@ Int VG_(main_pid);
Int VG_(main_pgrp);
+/* Maximum allowed application-visible file descriptor */
+Int VG_(max_fd);
+
/* Words. */
static Int baB_off = 0;
@@ -1110,5 +1113,5 @@ static void process_cmd_line_options ( c
/* Move logfile_fd into the safe range, so it doesn't conflict with any app fds */
- eventually_logfile_fd = VG_(fcntl)(VG_(clo_logfile_fd), VKI_F_DUPFD, VG_MAX_FD+1);
+ eventually_logfile_fd = VG_(fcntl)(VG_(clo_logfile_fd), VKI_F_DUPFD, VG_(max_fd)+1);
if (eventually_logfile_fd < 0)
VG_(message)(Vg_UserMsg, "valgrind: failed to move logfile fd into safe range");
@@ -1365,4 +1368,5 @@ void VG_(main) ( const KickstartParams *
{
VgSchedReturnCode src;
+ struct vki_rlimit rl;
/* initial state */
@@ -1415,4 +1419,23 @@ void VG_(main) ( const KickstartParams *
newpid(VG_INVALID_THREADID);
+ /* Get the current file descriptor limits. */
+ if (VG_(getrlimit)(VKI_RLIMIT_NOFILE, &rl) < 0) {
+ rl.rlim_cur = 1024;
+ rl.rlim_max = 1024;
+ }
+
+ /* Work out where to move the soft limit to. */
+ if (rl.rlim_cur + VG_N_RESERVED_FDS <= rl.rlim_max) {
+ rl.rlim_cur = rl.rlim_cur + VG_N_RESERVED_FDS;
+ } else {
+ rl.rlim_cur = rl.rlim_max;
+ }
+
+ /* Reserve some file descriptors for our use. */
+ VG_(max_fd) = rl.rlim_cur - VG_N_RESERVED_FDS;
+
+ /* Update the soft limit. */
+ VG_(setrlimit)(VKI_RLIMIT_NOFILE, &rl);
+
/* Read /proc/self/maps into a buffer. Must be before:
- SK_(pre_clo_init)(): so that if it calls VG_(malloc)(), any mmap'd
--- valgrind/coregrind/vg_mylibc.c #1.60:1.61
@@ -1204,5 +1204,5 @@ Int VG_(safe_fd)(Int oldfd)
Int newfd;
- newfd = VG_(fcntl)(oldfd, VKI_F_DUPFD, VG_MAX_FD+1);
+ newfd = VG_(fcntl)(oldfd, VKI_F_DUPFD, VG_(max_fd)+1);
if (newfd != -1)
VG_(close)(oldfd);
@@ -1210,5 +1210,5 @@ Int VG_(safe_fd)(Int oldfd)
VG_(fcntl)(newfd, VKI_F_SETFD, VKI_FD_CLOEXEC);
- vg_assert(newfd > VG_MAX_FD);
+ vg_assert(newfd > VG_(max_fd));
return newfd;
}
@@ -1430,4 +1430,15 @@ Int VG_(getrlimit) (Int resource, struct
+/* Support for setrlimit. */
+Int VG_(setrlimit) (Int resource, struct vki_rlimit *rlim)
+{
+ Int res;
+ /* res = setrlimit( resource, rlim ); */
+ res = VG_(do_syscall)(__NR_setrlimit, (UInt)resource, (UInt)rlim);
+ if(VG_(is_kerror)(res)) res = -1;
+ return res;
+}
+
+
/* Support for getdents. */
Int VG_(getdents) (UInt fd, struct vki_dirent *dirp, UInt count)
--- valgrind/coregrind/vg_syscalls.c #1.69:1.70
@@ -312,5 +312,5 @@ void record_fd_close(Int tid, Int fd)
OpenFd *i = allocated_fds;
- if (fd > VG_MAX_FD)
+ if (fd > VG_(max_fd))
return; /* Valgrind internal */
@@ -345,5 +345,5 @@ void record_fd_open(Int tid, Int fd, cha
OpenFd *i;
- if (fd > VG_MAX_FD)
+ if (fd > VG_(max_fd))
return; /* Valgrind internal */
@@ -890,5 +890,5 @@ static Bool valid_client_addr(Addr start
static Bool fd_allowed(Int fd, const Char *syscall, ThreadId tid)
{
- if (fd < 0 || fd > VG_MAX_FD || fd == VG_(clo_logfile_fd)) {
+ if (fd < 0 || fd > VG_(max_fd) || fd == VG_(clo_logfile_fd)) {
VG_(message)(Vg_UserMsg,
"Warning: invalid file descriptor %d in syscall %s()",
@@ -4156,5 +4156,5 @@ POST(socketcall)
case SYS_SOCKETPAIR:
- /* XXX TODO: check return fd against VG_MAX_FD */
+ /* XXX TODO: check return fd against VG_(max_fd) */
VG_TRACK( post_mem_write, ((UInt*)arg2)[3], 2*sizeof(int) );
if(VG_(clo_track_fds)) {
--- valgrind/include/vg_skin.h.base #1.2:1.3
@@ -397,4 +397,7 @@
extern Int VG_(getrlimit) ( Int resource, struct vki_rlimit *rlim );
+/* Set client resource limit*/
+extern Int VG_(setrlimit) ( Int resource, struct vki_rlimit *rlim );
+
/* Crude stand-in for the glibc system() call. */
extern Int VG_(system) ( Char* cmd );
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 02:12:23
|
CVS commit by fitzhardinge:
An experiment in generating branch-prediction hints. Enable them with
--branchpred=yes. I'm interested to know if these make a significant
difference for anyone - I see a small speed increase on the Pentium M.
M +55 -19 coregrind/vg_from_ucode.c 1.68
M +2 -0 coregrind/vg_include.h 1.160
M +7 -0 coregrind/vg_main.c 1.130
M +8 -2 include/vg_skin.h.base 1.2
M +10 -2 memcheck/mc_from_ucode.c 1.14
--- valgrind/coregrind/vg_from_ucode.c #1.67:1.68
@@ -81,4 +81,24 @@ static enum _eflags_state {
} eflags_state;
+/* ia32 static prediction is very simple. Other implementations are
+ more complex, so we get the condition anyway. */
+static JumpPred static_pred(Condcode cond, Int forward)
+{
+ if (cond == CondAlways)
+ return JP_TAKEN;
+
+ return forward ? JP_NOT_TAKEN : JP_TAKEN;
+}
+
+static const Char *predstr(JumpPred p)
+{
+ switch(p) {
+ default:
+ case JP_NONE: return "";
+ case JP_TAKEN: return ",pt";
+ case JP_NOT_TAKEN: return ",pn";
+ }
+}
+
/* single site for resetting state */
static void reset_state(void)
@@ -1938,6 +1958,7 @@ static inline Int tgt_addr(Int tgt)
static inline Int mk_tgt(Int state, Int addr)
{
- vg_assert(state == TGT_UNDEF
- || state == TGT_FORWARD || state == TGT_BACKWARD);
+ vg_assert(state == TGT_UNDEF ||
+ state == TGT_FORWARD ||
+ state == TGT_BACKWARD);
vg_assert((addr & 0xffff0000) == 0);
@@ -1998,24 +2019,36 @@ void VG_(emit_target_delta) ( Int *tgt )
offset is that which should be added to %eip once %eip has been
advanced over this insn. */
-void VG_(emit_jcondshort_delta) ( Bool simd_flags, Condcode cond, Int delta )
+void VG_(emit_jcondshort_delta) ( Bool simd_flags, Condcode cond, Int delta, JumpPred pred )
{
vg_assert(delta >= -128 && delta <= 127);
VG_(new_emit)(simd_flags, FlagsOSZCP, FlagsEmpty);
+
+ if (VG_(clo_branchpred) &&
+ pred != JP_NONE &&
+ pred != static_pred(cond, delta > 0))
+ VG_(emitB)(pred == JP_TAKEN ? 0x3e : 0x2e);
+
VG_(emitB) ( 0x70 + (UInt)cond );
VG_(emitB) ( (UChar)delta );
if (dis)
- VG_(printf)( "\n\t\tj%s-8\t%%eip+%d\n",
- VG_(name_UCondcode)(cond), delta );
+ VG_(printf)( "\n\t\tj%s-8%s\t%%eip+%d\n",
+ VG_(name_UCondcode)(cond), predstr(pred), delta );
}
/* Same as above, but defers emitting the delta */
-void VG_(emit_jcondshort_target) ( Bool simd, Condcode cond, Int *tgt )
+void VG_(emit_jcondshort_target) ( Bool simd, Condcode cond, Int *tgt, JumpPred pred )
{
VG_(new_emit)(simd, FlagsOSZCP, FlagsEmpty);
+
+ if (VG_(clo_branchpred) &&
+ pred != JP_NONE &&
+ pred != static_pred(cond, tgt_state(*tgt) != TGT_BACKWARD))
+ VG_(emitB)(pred == JP_TAKEN ? 0x3e : 0x2e);
+
VG_(emitB) ( 0x70 + (UInt)cond );
VG_(emit_target_delta) (tgt);
if (dis)
- VG_(printf)( "\n\t\tj%s-8\t%%eip+(%d)\n",
- VG_(name_UCondcode)(cond), tgt_addr(*tgt) );
+ VG_(printf)( "\n\t\tj%s-8%s\t%%eip+(%d)\n",
+ VG_(name_UCondcode)(cond), predstr(pred), tgt_addr(*tgt) );
}
@@ -2615,10 +2648,10 @@ static void synth_jcond_lit ( Condcode c
if (cond == CondLE) {
/* test Z */
- VG_(emit_jcondshort_target)(False, CondS, &tgt_jump);
+ VG_(emit_jcondshort_target)(False, CondS, &tgt_jump, JP_NONE);
/* test OF != SF */
cond = CondP;
} else {
/* test Z */
- VG_(emit_jcondshort_target)(False, CondS, &tgt2);
+ VG_(emit_jcondshort_target)(False, CondS, &tgt2, JP_NONE);
/* test OF == SF */
cond = CondNP;
@@ -2702,5 +2735,5 @@ static void synth_jcond_lit ( Condcode c
}
- VG_(emit_jcondshort_target) ( simd, cond, &tgt );
+ VG_(emit_jcondshort_target) ( simd, cond, &tgt, JP_NONE );
VG_(target_forward)(&tgt_jump);
@@ -2721,5 +2754,5 @@ static void synth_jmp_ifzero_reg_lit ( I
VG_(emit_cmpl_zero_reg) ( False, reg );
- VG_(emit_jcondshort_target) ( False, CondNZ, &tgt );
+ VG_(emit_jcondshort_target) ( False, CondNZ, &tgt, JP_NONE );
synth_jmp_lit ( addr, JmpBoring );
@@ -3235,5 +3268,5 @@ static void synth_cmovl_reg_reg ( Condco
VG_(init_target)(&tgt);
- VG_(emit_jcondshort_target) ( True, invertCondition(cond), &tgt);
+ VG_(emit_jcondshort_target) ( True, invertCondition(cond), &tgt, JP_NONE);
emit_movl_reg_reg ( src, dst );
@@ -4287,14 +4320,17 @@ UChar* VG_(emit_code) ( UCodeBlock* cb,
if (dis) VG_(printf)("Generated x86 code:\n");
- /* Generate decl VG_(dispatch_ctr) and drop into dispatch if we hit
+ /* Generate subl $1, VG_(dispatch_ctr) and drop into dispatch if we hit
zero. We have to do this regardless of whether we're t-chaining
- or not. */
+ or not. (The ia32 optimisation guide recommends sub over dec.) */
VG_(init_target)(&tgt);
VG_(new_emit)(False, FlagsEmpty, FlagsOSZAP);
- VG_(emitB) (0xFF); /* decl */
- emit_amode_litmem_reg((Addr)&VG_(dispatch_ctr), 1);
+ VG_(emitB) (0x83); /* subl */
+ emit_amode_litmem_reg((Addr)&VG_(dispatch_ctr), 5);
+ VG_(emitB) (0x01);
+
if (dis)
- VG_(printf)("\n\t\tdecl (%p)\n", &VG_(dispatch_ctr));
- VG_(emit_jcondshort_target)(False, CondNZ, &tgt);
+ VG_(printf)("\n\t\tsubl $1, (%p)\n", &VG_(dispatch_ctr));
+
+ VG_(emit_jcondshort_target)(False, CondNZ, &tgt, JP_TAKEN);
VG_(emit_movv_lit_reg) ( 4, VG_TRC_INNER_COUNTERZERO, R_EBP );
emit_ret();
--- valgrind/coregrind/vg_include.h #1.159:1.160
@@ -271,4 +271,6 @@ extern Bool VG_(clo_run_libc_freeres);
/* Use the basic-block chaining optimisation? Default: YES */
extern Bool VG_(clo_chain_bb);
+/* Generate branch-prediction hints? */
+extern Bool VG_(clo_branchpred);
/* Continue stack traces below main()? Default: NO */
extern Bool VG_(clo_show_below_main);
--- valgrind/coregrind/vg_main.c #1.129:1.130
@@ -587,4 +587,5 @@ Bool VG_(clo_chain_bb) = True;
Bool VG_(clo_show_below_main) = False;
Bool VG_(clo_pointercheck) = True;
+Bool VG_(clo_branchpred) = False;
static Bool VG_(clo_wait_for_gdb) = False;
@@ -693,4 +694,5 @@ void VG_(usage) ( void )
" --profile=no|yes profile? (tool must be built for it) [no]\n"
" --chain-bb=no|yes do basic-block chaining? [yes]\n"
+" --branchpred=yes|no generate branch prediction hints [no]\n"
" --trace-codegen=<XXXXX> show generated code? (X = 0|1) [00000]\n"
" --trace-syscalls=no|yes show all system calls? [no]\n"
@@ -897,4 +899,9 @@ static void process_cmd_line_options ( c
VG_(clo_chain_bb) = False;
+ else if (VG_CLO_STREQ(argv[i], "--branchpred=yes"))
+ VG_(clo_branchpred) = True;
+ else if (VG_CLO_STREQ(argv[i], "--branchpred=no"))
+ VG_(clo_branchpred) = False;
+
else if (VG_CLO_STREQ(argv[i], "--single-step=yes"))
VG_(clo_single_step) = True;
--- valgrind/include/vg_skin.h.base #1.1:1.2
@@ -1316,6 +1316,12 @@
extern void VG_(emit_target_delta) ( Int *tgt );
-extern void VG_(emit_jcondshort_delta) ( Bool simd_cc, Condcode cond, Int delta );
-extern void VG_(emit_jcondshort_target)( Bool simd_cc, Condcode cond, Int *tgt );
+typedef enum {
+ JP_NONE, /* no prediction */
+ JP_TAKEN, /* predict taken */
+ JP_NOT_TAKEN, /* predict not taken */
+} JumpPred;
+
+extern void VG_(emit_jcondshort_delta) ( Bool simd_cc, Condcode cond, Int delta, JumpPred );
+extern void VG_(emit_jcondshort_target)( Bool simd_cc, Condcode cond, Int *tgt, JumpPred );
--- valgrind/memcheck/mc_from_ucode.c #1.13:1.14
@@ -167,4 +167,6 @@ static void synth_SETV ( Int sz, Int reg
static void synth_TESTV ( Int sz, Int tag, Int val )
{
+ Int tgt; /* jump target */
+
/* Important note. Note that that the calls to
MC_(helper_value_check[0124]_fail) must be compact helpers due to
@@ -174,4 +176,6 @@ static void synth_TESTV ( Int sz, Int ta
sk_assert(sz == 0 || sz == 2 || sz == 4);
+ VG_(init_target)(&tgt);
+
sk_assert(tag == ArchReg || tag == RealReg);
if (tag == ArchReg) {
@@ -223,7 +227,10 @@ static void synth_TESTV ( Int sz, Int ta
}
}
- VG_(emit_jcondshort_delta) ( False, CondZ, 3 );
+
+ /* predict taken because we assume failures are rare */
+ VG_(emit_jcondshort_target) ( False, CondZ, &tgt, JP_TAKEN );
+
VG_(synth_call) (
- True, /* needed to guarantee that this insn is indeed 3 bytes long */
+ False,
( sz==4
? VG_(helper_offset)((Addr) & MC_(helper_value_check4_fail))
@@ -235,4 +242,5 @@ static void synth_TESTV ( Int sz, Int ta
False, FlagsEmpty, FlagsOSZACP /* helpers don't preserve flags */
);
+ VG_(target_forward)(&tgt);
}
|
|
From: Jeremy F. <je...@go...> - 2003-12-18 02:03:48
|
On Wed, 2003-12-17 at 17:32, Robert Walsh wrote: > Yup - Jeremy twiddled the fd tracking stuff to not record fds above > 820. Unfortunately, he forgot to change the close stuff to ignore > those, too... ;-) It's an easy fix. I deliberately report when close() is being used with a bad fd - it can be a symptom of a program closing wild file-descriptors if the fd is bad. But the "loop over all fds and close them" idiom is pretty common too. Maybe yet another CLO? J |
|
From: Robert W. <rj...@ke...> - 2003-12-18 01:48:37
|
CVS commit by rjwalsh:
Ignore internal Valgrind file descriptors.
M +3 -0 vg_syscalls.c 1.69
--- valgrind/coregrind/vg_syscalls.c #1.68:1.69
@@ -312,4 +312,7 @@ void record_fd_close(Int tid, Int fd)
OpenFd *i = allocated_fds;
+ if (fd > VG_MAX_FD)
+ return; /* Valgrind internal */
+
while(i) {
if(i->fd == fd) {
|
|
From: Robert W. <rj...@du...> - 2003-12-18 01:32:38
|
> Probably easier to track down, when running /opt/kde3/bin/kate on memcheck, > there are also hundreds of messages like this: > > ==5883== Warning: invalid file descriptor 822 in syscall close() > ==5883== at 0x3D505D71: close (in /lib/libc.so.6) > ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&, > char const*) > (in /opt/kde3/lib/kde3/libkonsolepart.so) > ==5883== by 0x3E1FD265: TEPty::commSetupDoneC() (in /opt/kde3/lib/kde3/ > libkonsolepart.so > ) > > running from fd=822 up to 1023. Sometimes it starts are 821 instead. > Any ideas? Yup - Jeremy twiddled the fd tracking stuff to not record fds above 820. Unfortunately, he forgot to change the close stuff to ignore those, too... ;-) It's an easy fix. Regards, Robert. |
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:16:15
|
On Wed, 2003-12-17 at 11:49, Julian Seward wrote: > I'm experiencing some turbulence on SuSE 9. > > Running any program on memcheck, there are a lot more uninit-val > errors reported than before. Even with 'ls'. Actually, did you make sure the defaults.supp got rebuilt? It may be that your system needs some more glibc/ld.so suppressions, since we're now running earlier code than we ever did. J |
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:12:22
|
On Wed, 2003-12-17 at 03:41, Tom Hughes wrote: > With RH9 it was complaining about syscall 258 which is set_tid_address > which is called by ld.so early on, so valgrind never used to see it. A > patch to add support for this is attached. What does set_tid_address do again? It might be better to just silently fail it with ENOSYS since we're not doing anything useful with that stuff yet. > Although simple programs worked, a debug build of one of our main > programs failed to mmap many of the shared objects. I managed to work > round this by adjusting VALGRIND_MAPSIZE in stage2.c to a little > over 300Mb in size. Debug builds of our software are somewhat extreme > in their use of shared libraries - this program had about 150 or so > and they mostly had level 3 DWARF debugging on. It should only be trying to map one of those in at once - do you really have a 100MByte+ .so file? > I noticed that if you track FD leaks then both /usr/bin/valgrind and > the client executable are reported as leaks. That shouldn't be. What fds is it finding them at? J |
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:09:50
|
On Wed, 2003-12-17 at 11:49, Julian Seward wrote: > I'm experiencing some turbulence on SuSE 9. > > Running any program on memcheck, there are a lot more uninit-val > errors reported than before. Even with 'ls'. Are the early? Are they in ld-linux.so? Are they str*() functions? > Probably easier to track down, when running /opt/kde3/bin/kate on memcheck, > there are also hundreds of messages like this: > > ==5883== Warning: invalid file descriptor 822 in syscall close() > ==5883== at 0x3D505D71: close (in /lib/libc.so.6) > ==5883== by 0x3E1FCB68: TEPty::startPgm(char const*, QValueList<QCString>&, > char const*) > (in /opt/kde3/lib/kde3/libkonsolepart.so) [...] > running from fd=822 up to 1023. Sometimes it starts are 821 instead. > Any ideas? As Tom said, this should occur in 2.1.0 as well - that's part of the syscalls changes. Maybe the trick would be to change the client's view of the soft (or hard) file-descriptor limit, in case they use that to work out what file-descriptors to close. Anyway, it's basically noise - maybe I shouldn't bother warning about those... J |
|
From: Jeremy F. <je...@go...> - 2003-12-18 01:07:34
|
On Wed, 2003-12-17 at 01:52, Josef Weidendorfer wrote: > That's another thing. --tracegen gives me nothing. If I do e.g. "valgrind -- > tool=none --trace-codegen ls &>log", code generation printout in log starts > at 0x81000D10. But I know for sure that my instrumentation is already called > for BB 0x81000C10, as the "mov" at 0x81000C10 calls the cache simulator (seen > when raising verbosity of my tool with --ct-verbose). Eh, are you saying that the --trace-codegen=10001 output only starts after 0x81000D10? I can't see any way in which can not print for early EIPs. BTW, could you also enable the VG_(printf) at the start of VG_(main) just to confirm the initial eip/esp values. > BTW: The auto-generated stage2.lds is working fine here on Suse 9.0. Great. J |