[Dpcl-develop] Some DPCL questions

[Steve C. <sl...@sg...>]

  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.