similar to: [LLVMdev] Dynamic number of registers

On Aug 18, 2012, at 8:51 PM, Sean Silva <silvas at purdue.edu> wrote: > Hi, I'm pondering using LLVM's backend pipeline to generate code for a > virtual machine (the DTrace DIF emulator) where the number of > registers must in general be queried dynamically*. Is this a > functionality that LLVM's backend pipeline currently supports? Does > LLVM's current

> It does, but you can dynamically reserve registers. So, if I'm understanding this correctly, the approach would then be to use a large upper bound on the number of registers (the instruction encoding limits it to 256, so that is safe), and then say "don't use registers [N,256)" in order to effectively codegen for registers [0,N)? Also, could you provide me some pointers to

Has anyone seen the following error before? "error on enabled probe ID 2 (ID 473: sdt:unix:av_dispatch_autovect:interrupt-complete): invalid address (0x198) in action #3 at DIF offset 20" I''m trying to capture interrupt times as inlined in the below script. The script gives me some output after the errors, and I''m trying to understand if the errors are affecting

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n

Hi, In Solairs Dtrace User Guide, page 193, it lists the arguments of ERROR probe. One of these arguments is arg3, it is explained as "The DIF offset into that action or -1 if not applicable". Then what does the abbr. DIF mean? Regards TJ

Hi, I ran a d-program with syscall::open:entry probe but got the following error messages sometimes: dtrace: error on enabled probe ID 1 (ID 14: syscall::open:entry): invalid address (0xff34e000) in predicate at DIF offset 76 dtrace: error on enabled probe ID 6 (ID 14: syscall::open:entry): invalid address (0xff34e000) in predicate at DIF offset 28 I don''t know how to interpret these

Bryan, I''m trying to use a Dtrace script with a modest size global variable and hit a problem. Looking for a solution, I turn to the docs and notice that option "dynvarsize" appears just once in the docs, and it refers you to Chapter 3, where there is no mention. It doesn''t help me anyhow. I have: #!/usr/sbin/dtrace -qws #pragma D option dynvarsize=2000000

Hi all... I''ve just got my hands on a Solaris 10 box for the first time. I''ve heard wonderous things about dtrace, so the first command I type is dtrace -l which disappointingly does nothing at all. It just hangs, and neither Ctrl-D, Ctrl-C or kill -9 from another shell will do anything to kill it. The box is: SunOS t2000 5.10 Generic_118822-25 sun4v sparc SUNW,Sun-Fire-T200

G''Day Folks, I''ve found another use of dtrace, this makes your console keyboard sound like a typewriter. http://www.brendangregg.com/DTrace/typewriter-0.70.tar.gz I''ve only tested it on an UltraSPARC 5 and a Pentium laptop so far, more to follow. Ok, sorry, not actually a practical use of DTrace. :) Enjoy! Brendan [Sydney, Australia]

What''s going on? # dtrace -s iotime_all.d 100 dtrace: failed to enable ''iotime_all.d'': DIF program content is invalid The errant script.... #pragma D option quiet BEGIN { stime = timestamp; io_count = 0; } io:::start /args[2]->fi_pathname != "<none>"/ { start[pid, args[2]->fi_pathname, args[0]->b_edev, args[0]->b_blkno,

Tried to start up tcptop_snv on snv87 x86 and got <i>dtrace: failed to compile script /dev/fd/11: line 168: conn_tcp is not a member of struct conn_s</i> Line 288 has this line: <i>this->tcpp = (tcp_t *)this->connp->conn_tcp;</i> which, after looking at line 168 of <a

hi, I''m using the PID provider to trace a 32-bit app, prtdiag. I''m trying to print the value of "propname" (arg1) in the following func: int picl_get_propval_by_name(picl_nodehdl_t nodeh, const char *propname, void *valbuf, size_t nbytes) ... i''ve tried many versions, but this is a representative one: 53 this string propname; 54 55

Oh I see. Thank you. I will study that. Journeyer 2013/1/13 Sean Silva <silvas at purdue.edu>: > You can easily collect this information with DTrace on a Mac (or > Solaris or FreeBSD) without any special LLVM instrumentation. > > -- Sean Silva -- ---------------------------------------- Journeyer J. Joh o o s a p r o g r a m m e r a t g m a i l d o t c o m

N_conreq:entry { self->x=1; calledaddr=(struct xaddrf *)arg3; callingaddr=(struct xaddrf *)arg4; trace(calledaddr->link_id); tracemem(calledaddr->DTE_MAC.lsap_add, 80); trace(callingaddr->link_id); tracemem(callingaddr->DTE_MAC.lsap_add, 80); } 0 -> N_conreq 255

On Tue, Nov 12, 2013 at 7:24 PM, Sean Silva <silvas at purdue.edu> wrote: > Could you maybe give an example or two to whet our testing appetite? It would honestly be simpler for me to write the tests after pulling it in and point at them. The GoogleMock project has some good examples as well. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, Has something related to speculative tracing changed between s10 FCS and the more recent nevada builds ? I was trying the specopen.d script from the Dtrace guide on a nevada machine and it failed with : dtrace: failed to enable ''./spec.d'': DIF program content is invalid To try and narrow things down a bit I wrote the following short script. This works fine on s10, but

This is a semantic question. (I''m doing some technical writing about DTrace.) I''ll little confused about how to explain what an "action" is. By any definition, "trace(x);" is an action. However, what about just "i++;"? Looking at the DTrace guide page 76: "Probe actions are described by a list of statements separated by semicolons (;)

A user has asked us to find out who is changing one of their files and how it is being changed. I came up with the script below: #!/usr/sbin/dtrace -s #pragma D option quiet BEGIN { printf("\n Timestamp gid uid pid ppid execname function current directory file name\n\n"); } syscall::open:entry,

On Sat, Jan 12, 2013 at 10:00 PM, Journeyer J. Joh <oosaprogrammer at gmail.com> wrote: > Oh I see. Thank you. I will study that. You will want to use the pid provider. The most basic thing you can probably do is to turn on flowindent and just trace `pid$target:::entry' and `pid$target:::return`, which will trace all the function calls and returns. This blog post

We cannot run the zilstat utility (from http://www.richardelling.com/Home/scripts-and-programs-1/zilstat) on an Solaris 10 u9 / x86 installed according SUNWCreq (which is a core install) while it works fine on a similar config but installed with all packages (SUNWCXall) So we know it works in this environment but it seems we miss an essential package here. That causes the dtrace: failed to