Re: [Dpcl-develop] Some DPCL questions

[Dave W. <dwo...@us...>]

Steve
Your email has not been getting thru until this one. In response to your 
questions:

1) There's no reason why callbacks should stop after 45 executions of the 
probe expression. What happens here? Does DPCL just hang, crash, or 
execute normally? Probably the best thing to do is put a call to 
Ais_blog_on just before you set up the probe and see what is going on. We 
should see probe  exp activity in the DPCL log

2) What happens with the unaligned references on ia64? Do you just get a 
warning and DPCL continues, or does DPCL crash? If we track these down, we 
are going to have to do this on a case by case basis with most of them in 
the various mesaage pack and unpack functions where we are building 
messages between client and daemon.

I understand the reason ia64 is complaining about unaligned references, 
but this is the first hardware/software I have seen lately that seems to 
complain. If there are no serious side effects to the unaligned 
references, is there possibly a function call that could be made to turn 
off this warning?

3) I don't think you can do what you want, i.e. calling sleep() with DPCL. 
The problem is that DPCL only knows about functions within the target 
executable. It has no knowledge of functions in any shared libraries. We 
get around this limitation in AIX by taking advantage of how library calls 
are made in AIX applications. On AIX, a call to a library function is made 
by calling a small stub module which gets linked with the application, and 
the stub then makes the call to the real library function. Since the stubs 
are linked with the application, we can find the stub and put pur probes 
there. Even with this solution, DPCL can only call functions which are 
referenced by the application already. If the application never calls 
sleep(), then DPCL cannot build a probe expression to call it since the 
stub doesn't exist.

On ia32 Linux we can't take advantage of this solution since the generated 
assembler code calls the library function directly. I suspect Linux on 
ia64 works the same way.

Dave




Steve Collins <sl...@sg...>
Sent by: dpc...@ww...
02/26/2004 02:15 PM
 
        To:     dpc...@ww...
        cc:     sl...@sg..., per...@co...
        Subject:        [Dpcl-develop] Some DPCL questions





  I've been having e-mail problems recently so I suspect my
 postings here have not been received by everyone. So I am going
 to re-post and hope for better results. I am currently trying to
 address 3 DPCL issues as described below. Thanks as always to
 DaveW, JamesW and others who might relieve my current clueless
 state regarding any or all of these DPCL issues. 


                                                SteveC
                                                SGI Tools
  1. 

    I have a DPCL testcase (aka Dyninst mutator) that simply attempts
 to insert a call to 'sleep' into the 'mutatee'. This seems to work
 great until I ask for more than 45 calls to 'sleep'. Even if I ask
 for 4000 calls or just 47 calls to sleep, I only get 45 'callbacks' 
 to occur to my mutator (or client or tool, etc.). It's like the
 callback mechanism works for some limit of approximately 45 times.
 I KNOW that I am entering the 'sleep' function 5000 times but only
 45 callbacks from the instrumentation are occurring. Only 45 callbacks
 occur if I just specify 47 calls to sleep. There <seems> to be a
 barrier at '45' when it comes to the number of callbacks that will
 or can occur. I have no clue on this one.

  2.

   Some of the DPCL code (example provided below) is causing the
 IA64 hardware to emit 'unaligned access' errors to the screen.
 An example of the code occurs in ~dpcl/src/lib/src/ModuleId.C
 in routine 'ModuleId unpack_ModuleId(char **buffer)', to wit:

   ModuleId
unpack_ModuleId(char **buffer)
{
    char *data = *buffer;

    char *uniqstr = data;
    data = data + 1 + strlen(uniqstr); // don't forget the NULL character

    int *uint_p = (int *) data;
    data = data + sizeof(int);
    ModuleId new_mid = ModuleId(uniqstr, *uint_p);

       .....

  This last statement which derefernces from an 'int' alignment (*uint_p)
  seems to upset the ia64 hardware and I get something like this:

mutator(16567): unaligned access to 0x600000000000aa36, 
ip=0x2000000000277bb0

  Now this code can be rewritten to avoid this hardware complaint, but it
 is probably a change that needs to be made in a number of places. Getting
 changes accepted on a voluminous scale would seem to be problematic. Is
 that true, or am I just being a little paranoid?


  3. 

    I have a DPCL testcase (aka Dyninst mutator) that simply attempts
 to insert a call to 'sleep' into the 'mutatee'. We have discovered that
 'weak' symbols such as 'sleep' are not found by DPCL but they are found 
 by Dyninst.  To wit:

The problem with sleep() rather than __sleep() is that the former is a
weak symbol:

[hope] /scratch/wdh/Test/DPCL: objdump -t /lib/libc.so.6.1 | grep "sleep"
...
0000000000160890 l     F .text  00000000000003a0              __sleep
...
0000000000160890  w    F .text  00000000000003a0              sleep
...

Now I'm not sure why Dyninst works fine with the weak sleep(), but DPCL
doesn't.

 (Note: the above analysis by Bill Hachfeld at SGI)

DaveW/James - have you seen any problem of this sort in the past involving
'weak' symbols?  For reminders, we are running on an ia64 machine.

_______________________________________________
Dpcl-develop mailing list
Dpc...@ww...
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/dpcl-develop