Re: 'recording' program execution.

[wuxi]

[EMAIL PROTECTED] wrote:
have a look at the flag -finstrument-functions for gcc. 

as far as I know, this could only record at function entry and return ?

but sometimes recording all the "trace" of how program behaves is useful 
for debugging purpose.


further, using a binary instrumentation tool like PIN could only record 
the low level instruction trace

"Annotate" INSN in gcc

[wuxi]

Hi,

I am working on IA64 and gcc4.1.1. My primary work is to use control 
speculation on IA64 to implement efficient taint tracking. We have 
already had a paper on ISCA'08.


For this purpose, I add a pass (before the 2nd instruction scheduling) 
to instrument loads, stores, and compares. During the pass, I identify 
each INSN by "manually" matching their patterns (since at that time, 
INSNs in gcc have not bee fully recognized, I have to write my own 
recognizers for instructions).


However, the downside of this approach is that I may miss some 
instructions (though most of the instructions have been instrumented), 
and these uninstrumented ones (though rare) will bring bizarre bugs into 
the instrumented program. (recently I find one such bug in my 
instrumented program, missing to instrument one instruction in about 
30, instructions...)


So now, I want to add some checking in final to see if my 
instrumentation is complete. The basic thing I want to do is to 
associate some attributes to the INSN I want to instrument, and also my 
instrumentation INSNs, in the added pass. Later in final, I could use 
GCC's INSN_CODE (or perhaps INSN template) to match all INSNs and see 
whether I have done all things right.


NOW my problem is: could GCC do this work easily, or I should add my own 
data structure to record instrumented INSN? I have read some doc about 
insn attributes, but it seems that they do not fit into my needs...


NOTE: the attributes should be bundled with the INSN, they should go 
along with INSN in other passes, e.g. scheduling, and should not be 
deleted by other passes.


Any help is truly appreciated :-)

Thanks !

yours sincerely

Andrew

Cannot understand the reloading code

[wuxi]

Hi,

I am working on Itanium and gcc4.1.1. My work is mainly do 
instrumentations to enable efficient taint tracking (using NaT bit on 
IA-64 to represent tainted data.) on IA-64.(recently i am porting my 
code to gcc4.3.2, but that has not been accomplished, because i should 
also port my modified glibc to a compatible version with gcc4.3.2).


Some modifications recently is, I move some of my instrumentations up 
before life analysis, and I allocate pseudo registers to do the 
instrumentation. From the INSN list after my pass, it seems that all 
instrumentation is done well. And for each sensitive INSN I care, I 
allocate enough pseudo registers to do instrumentation, by calling 
gen_reg_rtx to allocate new pseudos. For example, the following is a 
sequence for instrumenting a cmp instruction IA-64:


=
the INSN I want to instrument is :
(insn 21 46 47 0 (set (reg:BI 343)
   (eq:BI (reg/v:SI 339 [ zipfile ])
   (const_int -1 [0x]))) 233 {*cmpsi_normal} (nil)
   (nil))
=

=
after instrumentation, it becomes the following INSN list:

r346 is the pseudo register allocated for instrumentation.

//this instruction is the "tnat" instruction I added in ia64.md, it test 
the NaT bit of r399

(insn 43 19 44 0 (set (reg:BI 346)
   (unspec:BI [
   (reg:DI 339)
   ] 32)) -1 (nil)
   (nil))

// st8.spill r399 into [r0] (i allocated memory for NULL), the goal here 
is to clear NaT bit

(insn 44 43 46 0 (cond_exec (ne:BI (reg:BI 346)
   (const_int 0 [0x0]))
   (parallel [
   (set (mem:DI (reg/f:DI 0 r0) [0 S8 A64])
   (unspec:DI [
   (reg:DI 339)
   (const_int 0 [0x0])
   ] 10))
   (clobber (reg:DI 330 ar.unat))
   ])) -1 (nil)
   (nil))

// load it again, now r339 won't have NaT bit
(insn 46 44 21 0 (cond_exec (ne:BI (reg:BI 346)
   (const_int 0 [0x0]))
   (set (reg:DI 339)
   (mem:DI (reg/f:DI 0 r0) [0 S8 A64]))) -1 (nil)
   (nil))

// do real cmp
(insn 21 46 47 0 (set (reg:BI 343)
   (eq:BI (reg/v:SI 339 [ zipfile ])
   (const_int -1 [0x]))) 233 {*cmpsi_normal} (nil)
   (nil))

// restore the NaT bit for r339
(insn 47 21 22 0 (cond_exec (ne:BI (reg:BI 346)
   (const_int 0 [0x0]))
   (set (reg:DI 339)
   (plus:DI (reg:DI 4 r4)
   (reg:DI 339 -1 (nil)
   (nil))

=

Now the problem comes, when global allocation completes, there is still 
pseudo register. In the dump file .greg, I found the following:


Reloads for insn # 43
Reload 0: reload_in (DI) = (reg:DI 339)
   GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
   reload_in_reg: (reg:DI 339)
   reload_reg_rtx: (reg:DI 14 r14)

the spilling info says:
Spilling for insn 43.
Using reg 14 for reload 0

This is correct, and I found the INSN list above, all r339 have been 
replaced by r14.


But there is an extra INSN inserted, that is:
(insn 57 7 43 0 (set (reg:DI 14 r14)
   (reg:DI 339)) 5 {*movdi_internal} (nil)
   (nil))

how can r339 appears again? this is spilling? I am confused by this.

So any help, I want some advices to help me where I should dig into to 
resolve this problem. I have been reading code in reload1.c, 
particularly inc_for_reload, I observe it will generate emit_move_insn 
for some purpose, but I don't quite understand...


Any help is truly appreciated :-)

Thanks!

yours sincerely

Andrew