dpcl-develop — DPCL Development list

[Dpcl-develop] [SPAM] Your S.O.A. May-14_#14052024 lists.sourceforge.net

[Accounts_Payable_Team <hi...@ct...>]

As instructed by our customer earlier, see below Statement of Account.  Please check and confirm documents to facilitate remittance. 



 
S.O.A. May-14_#14052024.XLS

[Dpcl-develop] Dokumenty

[M. Z. <mz...@tl...>]

Witam,

Zwracam się z zapytaniem w imieniu internetowego
serwisu tłumaczeniowego.

Polscy przedsiębiorcy szukają dobrych jakościowo tłumaczeń w związku
z rosnącym eksportem i chęcią nawiązywania międzynarodowej
współpracy.

Chciałem się zapytać czy mogę przedstawić ofertę na usługi
tłumaczeń
pisemnych?

Pozdrawiam,
Maciej Zieliński
Senior Account Manager
Tlumaczunas.pl

[Dpcl-develop] DPCL 3.4.4 for AIX available for download

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

DPCL 3.4.4 for AIX is available for download. This release fixes the 
following bug:
1736659 - DPCL hang after processing create and terminate for parallel 
application on Power 4 systems with AIX bos.mp 5.3.0.60 installed.

If this fix is not installed, you can work around the problem by manually 
killing the dpcld (and sesmgr PE Benchmarker process) owned by your userid
Dave

[Dpcl-develop] DPCL 3.4.3 release available for download

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

DPCL 3.4.3 is now available for download from the DPCL project download 
page (http://sourceforge.net/project/showfiles.php?group_id=128800). The 
files contained in this release are listed under the DPCL production 
releases category.

This release fixes a couple problems which have been reported since the 
v342 release.

Dave

[Dpcl-develop] DPCL Release 3.4.2 available

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

DPCL release 3.4.2 is available for download from 
http://sourceforge.net/project/showfiles.php?group_id=128800&package_id=143438. 
This release is intended for production use.

The major changes in this release
  Support for instrumentation at the block level of application source 
code (AIX only). See http://dpcl.sourceforge.net/doc/sourceblock.html for 
details.
  Enhancements to improve scaling and memory utilization when running DPCL 
on large systems.
  Enhancements to improve ability of DPCL to handle installing large 
numbers of probes in an application
  Fixes to various DPCL daemon termination problems

In addition, this release includes the following bug fixes
  SIGSEGV in DPCL daemom when calling destructor for a ModuleObj object
  Problem loading probe modules in 64 bit target applications
  Target application gets SIGSEGV when DPCL attempts to instrument shared 
object
  Target application gets SIGILL when removing probes
 
For more information about DPCL, visit http://dpcl.sourceforge.net

Dave
 

Re: [Dpcl-develop] DPCL and SIGCHLD/SIGTRAP

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

Steve
How often are you encountering this in running DPCL with Dyninst 4.2.1?

We spent a little time this afternoon, but this needs more investigation 
to understand the scope of the problem and possible solution. 

We did look at the call to waitpid in the shared memory code. The code in 
this area is trying to handle the case where dpcld is attempting to obtain 
a shared memory lock which the mutatee is holding. Normally obtaining the 
lock should not be a problem, and the waitpid call should not be issued. 

Where DPCL gets into trouble is when the mutatee raises any signal. Since 
the mutatee is under ptrace control with DPCL being the controlling 
program, the mutatee gets suspended. If the signal is raised and the 
mutatee suspended while the shared memory lock is held, then DPCL will not 
be able to obtain that lock. The shared memory code retries the request to 
get the lock 100 times. If it cannot obtain the lock after 100 retries, it 
assumes that the mutatee is stopped for some reason. So, the shared memory 
code issues a waitpid for the pid of the mutatee holding the lock and 
evaluates the status returned by the waitpid call. If that status 
indicates that the process is stopped, then the shared memory code sends 
the mutatee process a SIGCONT in order to resume the process, since 
presumably, the mutatee would continue processing, clear the shared memory 
lock, and allow the dpcld shared memory code to get the lock.

If the mutatee got suspended because of, for instance, execution of a trap 
instruction placed by Dyninst, and the subsequent SIGTRAP signal, then 
when the shared memory code issues the waitpid, it will incorrectly get 
and handle the status for the signal and Dyninst will of course never get 
the SIGTRAP notification.

We talked about a solution, which may not be the right approach, and needs 
to be investigated further. If the shared memory code was to retry 
obtaining the lock for an extended period of time, and was unable to do 
so, it might assume that the mutatee has somehow gotten hung and will 
never release the lock. In that case, the shared memory code may force the 
lock to cleared state so that it can then obtain it and continue with it's 
processing. This has the risk that if the mutatee is only running slowly, 
the mutatee may update shared memory structures that it thinks it holds 
the lock for when it does not, and those structures may be corrupted, 
resulting in a mutatee and/or dpcld crash, neither of which is desirable.

We also need to look at the other daemon calls to waitpid to see what the 
intent of the code in those areas is.

Dave



Steve Collins <sl...@sg...> 
Sent by: dpc...@li...
05/02/2005 11:34 AM

To
dpc...@li...
cc
sl...@sg..., Dave Wootton/Poughkeepsie/IBM@IBMUS, leg...@cs..., 
ja...@cs..., be...@cs..., per...@sg...
Subject
[Dpcl-develop] DPCL and SIGCHLD/SIGTRAP







   Greetings, everyone. I need to bounce a DPCL concern off the experts
 on this board. The recent Dyninst 4.2.1 release has exposed a stability
 issue with the Hybrid version of DPCL. Code that used to be seemingly
 innocuous with Dyninst 4.1.1 has proven to be incompatible with the
 newer, improved process and/or thread control that Dyninst 4.2.1 
provides.
 The problematic code is in 'main.C' of the CommDaemon (dpcld) and it
 involves the unblocking of SIGCHLD and SIGTRAP signals. To be sure this
 is just an issue with the University Dyninst (_DYNINST) implementation,
 but it is potentially destabilizing for the Open|SpeedShop project at
 SGI (Silicon Graphics). 
   Following are some comments from Matt Legendre and Drew Bernat from
 the Dyninst Group when informed that the Hybrid version of DPCL registers
 for and unblocks SIGCHLD and SIGTRAP signals headed for the mutatee. In 
 the case of SIGCHLD, DPCL makes process control dicey by doing a 
'waitpid'
 in its 'sigchild_handler' as well as a 'waitpid' in its shared memory
 manager code. By accepting SIGTRAP signals for the mutatee, DPCL also is
 asking for trouble by interfering with Dyninst's trap-based 
instrumentation.
 Frankly, I think this code is something left over from the original 
Hybrid
 'creation' effort and DPCL (University Dyninst version only) should have 
 been changed to forget about SIGCHLD and SIGTRAP some time ago. But my 
 confidence is real shaky when I say this. Thus I am posting here for some 

 reinforcement(s).
   Comments and/or reactions welcome.

                                     Steve Collins, SGI Compilers/Tools
 
  Drew Bernat writes:

> Dyninst uses signals for:
>
> 1) Trap-based instrumentation if we can't fit a jump in.
> 2) Discovering the completion of an inferior RPC (forcing code to run in
> the mutatee)
> 3) Discovering loads of new shared libraries (a trap in dlopen)
> 4) On  Linux, discovery of when several system calls are executed.
> 5) Keeping track of process state (paused/running)
> and 6) discovering when a mutatee exits.
>
>
> The big one is trap-based instrumentation, followed closely by tracking
> process state. I'll let Matt fill in more details.

  Matt Legendre writes:

> I think Drew caught all of the big places where Dyninst makes use of
> waitpid, it's a fundamental part of the ptrace debugging interface on
> Linux.  And we call it frequently.  Anytime BPatch::waitForStatusChange 
or
> BPatch::pollForStatusChange is called, anytime instrumentation is
> inserted, anytime the process is stopped, or anytime we try to 
read/write
> from it's address space, anytime a fork/exec happens.

> If DPCL is also calling waitpid frequently, then we stand a good chance 
of
> having DPCL get one of our signal events, or we get one of DPCL's.

> If we get an event generated by DPCL that we don't recognize it's likely
> to be silently dropped (SIGTRAP), forwarded back to the process
> (SIGPROF), or handled as if we caused it (SIGCHLD).

> If DPCL picks up one of our events, a lot of things could happen:

>  * We'll fail to execute instrumentation and incorrectly execute part of
> the program (if we miss a SIGTRAP from trap-based instrumentation).
> Fortunately, the use of trap based instrumentation is rare.

> * Not know about a new shared library that's been loaded (A SIGTRAP
> generated from dlopen).  We won't generate parse data for this library
> or be able to instrument it, but app will continue to run fine.  We may
> not have seen that yet because not too many applications use dlopen.

> * Miss certain system calls that are being executed.  I don't think this
> is a frequently used feature of Dyninst.  We'll miss things like exec
> system calls, which the test applications might not be doing.

> * Missing the mutatee when it exits, which is what we're seeing now.
> Dyninst (as it currently stands) isn't going to change the process 
status
> to 'exited' until it sees this event.

> * If DPCL is also calling ptrace(PTRACE_CONT, ...) when we expect the
> process to be stopped, that's going to cause us to lose track of the
> process state and will probably cause certain operations (like inserting
> instrumentation) to start failing until the two sync back up.

> Now most of these aren't critical-fail-on-every-run errors, which is
> probably why we didn't see them before, but they're still unacceptable
> from a stability stand point.  Unfortunately, I don't have a good
> suggestion for fixing this.  Working around this from a pure Dyninst 
stand
> point would be incredibly difficult. 
> 

  Steve Collins writes:

>The basic DPCL signal handler for SIGCHLD does a 'waitpid'. But it has
>always done that and things worked, at least with Dyninst 4.1.1.; maybe
>4.2.1 has rendered the DPCL SIGCHLD handler 'bad'.


  Drew Bernat writes:

> Dyninst is designed with the
> assumption that it is the only thing consuming signals from the child;
> as a result, when a child dies we _will_ get a SIGCHLD from it so that
> we can clean up. I'm not surprised that some things may have worked in
> the past, but it's an error case that we explicitly don't test here. As
> an example, the internal call to terminateProc() was hanging with 4.1.1
> because we didn't get informed of the child dying; now it's pause(), but
> the root cause is the same.

> We can patch pause() to operate correctly, but there will still be
> problems when we don't catch a process dying.
> I'm bouncing this to Matt, the signals expert. It looks like DPCL is
> calling waitpid, which is just plain bad news. And it's forwarding
> signals, which is worse.

> The biggest problem is going to be Dyninst process control. However,
> _particularly_ on Linux (cruddy debugging interface), we really need as
> much information as we can get. That includes waitpid(), unfortunately.
> It makes sense as a monolithic structure, but not if it's handing
> process control to Dyninst. Problem is, Dyninst gives you process
> control along with instrumentation.

> As a note, this was likely to break the other way in Dyninst 5.0. One
> of the upcoming features is an internally multithreaded Dyninst library
> so that the user doesn't have to call "pollForStatusEvents" all the
> time; this means that Dyninst would probably catch the DPCL signals
> rather than the reverse.


Steve Collins wrote:

> Drew -
>   Oh yeah, I think we can safely assume it is just the SIGCHLD signal.
> They use the handler to 'ptrace (PT_CONTINUE) the mutatee.
>


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Dpcl-develop mailing list
Dpc...@li...
https://lists.sourceforge.net/lists/listinfo/dpcl-develop

[Dpcl-develop] DPCL and SIGCHLD/SIGTRAP

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

   Greetings, everyone. I need to bounce a DPCL concern off the experts
 on this board. The recent Dyninst 4.2.1 release has exposed a stability
 issue with the Hybrid version of DPCL. Code that used to be seemingly
 innocuous with Dyninst 4.1.1 has proven to be incompatible with the
 newer, improved process and/or thread control that Dyninst 4.2.1 provides.
 The problematic code is in 'main.C' of the CommDaemon (dpcld) and it
 involves the unblocking of SIGCHLD and SIGTRAP signals. To be sure this
 is just an issue with the University Dyninst (_DYNINST) implementation,
 but it is potentially destabilizing for the Open|SpeedShop project at
 SGI (Silicon Graphics). 
   Following are some comments from Matt Legendre and Drew Bernat from
 the Dyninst Group when informed that the Hybrid version of DPCL registers
 for and unblocks SIGCHLD and SIGTRAP signals headed for the mutatee. In 
 the case of SIGCHLD, DPCL makes process control dicey by doing a 'waitpid'
 in its 'sigchild_handler' as well as a 'waitpid' in its shared memory
 manager code. By accepting SIGTRAP signals for the mutatee, DPCL also is
 asking for trouble by interfering with Dyninst's trap-based instrumentation.
 Frankly, I think this code is something left over from the original Hybrid
 'creation' effort and DPCL (University Dyninst version only) should have 
 been changed to forget about SIGCHLD and SIGTRAP some time ago. But my 
 confidence is real shaky when I say this. Thus I am posting here for some 
 reinforcement(s).
   Comments and/or reactions welcome.

                                     Steve Collins, SGI Compilers/Tools
 
  Drew Bernat writes:

> Dyninst uses signals for:
>
> 1) Trap-based instrumentation if we can't fit a jump in.
> 2) Discovering the completion of an inferior RPC (forcing code to run in
> the mutatee)
> 3) Discovering loads of new shared libraries (a trap in dlopen)
> 4) On  Linux, discovery of when several system calls are executed.
> 5) Keeping track of process state (paused/running)
> and 6) discovering when a mutatee exits.
>
>
> The big one is trap-based instrumentation, followed closely by tracking
> process state. I'll let Matt fill in more details.

  Matt Legendre writes:

> I think Drew caught all of the big places where Dyninst makes use of
> waitpid, it's a fundamental part of the ptrace debugging interface on
> Linux.  And we call it frequently.  Anytime BPatch::waitForStatusChange or
> BPatch::pollForStatusChange is called, anytime instrumentation is
> inserted, anytime the process is stopped, or anytime we try to read/write
> from it's address space, anytime a fork/exec happens.

> If DPCL is also calling waitpid frequently, then we stand a good chance of
> having DPCL get one of our signal events, or we get one of DPCL's.

> If we get an event generated by DPCL that we don't recognize it's likely
> to be silently dropped (SIGTRAP), forwarded back to the process
> (SIGPROF), or handled as if we caused it (SIGCHLD).

> If DPCL picks up one of our events, a lot of things could happen:

>  * We'll fail to execute instrumentation and incorrectly execute part of
> the program (if we miss a SIGTRAP from trap-based instrumentation).
> Fortunately, the use of trap based instrumentation is rare.

> * Not know about a new shared library that's been loaded (A SIGTRAP
> generated from dlopen).  We won't generate parse data for this library
> or be able to instrument it, but app will continue to run fine.  We may
> not have seen that yet because not too many applications use dlopen.

> * Miss certain system calls that are being executed.  I don't think this
> is a frequently used feature of Dyninst.  We'll miss things like exec
> system calls, which the test applications might not be doing.

> * Missing the mutatee when it exits, which is what we're seeing now.
> Dyninst (as it currently stands) isn't going to change the process status
> to 'exited' until it sees this event.

> * If DPCL is also calling ptrace(PTRACE_CONT, ...) when we expect the
> process to be stopped, that's going to cause us to lose track of the
> process state and will probably cause certain operations (like inserting
> instrumentation) to start failing until the two sync back up.

> Now most of these aren't critical-fail-on-every-run errors, which is
> probably why we didn't see them before, but they're still unacceptable
> from a stability stand point.  Unfortunately, I don't have a good
> suggestion for fixing this.  Working around this from a pure Dyninst stand
> point would be incredibly difficult.  
> 

  Steve Collins writes:

>The basic DPCL signal handler for SIGCHLD does a 'waitpid'. But it has
>always done that and things worked, at least with Dyninst 4.1.1.; maybe
>4.2.1 has rendered the DPCL SIGCHLD handler 'bad'.


  Drew Bernat writes:

> Dyninst is designed with the
> assumption that it is the only thing consuming signals from the child;
> as a result, when a child dies we _will_ get a SIGCHLD from it so that
> we can clean up. I'm not surprised that some things may have worked in
> the past, but it's an error case that we explicitly don't test here. As
> an example, the internal call to terminateProc() was hanging with 4.1.1
> because we didn't get informed of the child dying; now it's pause(), but
> the root cause is the same.

> We can patch pause() to operate correctly, but there will still be
> problems when we don't catch a process dying.
> I'm bouncing this to Matt, the signals expert. It looks like DPCL is
> calling waitpid, which is just plain bad news. And it's forwarding
> signals, which is worse.

> The biggest problem is going to be Dyninst process control. However,
> _particularly_ on Linux (cruddy debugging interface), we really need as
> much information as we can get. That includes waitpid(), unfortunately.
> It makes sense as a monolithic structure, but not if it's handing
> process control to Dyninst. Problem is, Dyninst gives you process
> control along with instrumentation.

> As a note, this was likely to break the other way in Dyninst 5.0. One
> of the upcoming features is an internally multithreaded Dyninst library
> so that the user doesn't have to call "pollForStatusEvents" all the
> time; this means that Dyninst would probably catch the DPCL signals
> rather than the reverse.


Steve Collins wrote:

> Drew -
>   Oh yeah, I think we can safely assume it is just the SIGCHLD signal.
> They use the handler to 'ptrace (PT_CONTINUE) the mutatee.
>

[Dpcl-develop] Re: Bug 1181583 (SF) - correct # params for SSM_dsend call

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

Steve
The patch is fine. You can do the commit.

Dave



Steve Collins <sl...@sg...> 
04/12/2005 04:29 PM

To
Dave Wootton/Poughkeepsie/IBM@IBMUS
cc

Subject
Bug 1181583 (SF) - correct # params for SSM_dsend call








  Dave -

      This is a bug but it works by dump luck, as you said some time ago.
    Review should be pretty simple - I just added a 4th, correct paramater
    to the SSM_dsend call.

                                             SteveC
[attachment "foo" deleted by Dave Wootton/Poughkeepsie/IBM] 

Re: [Dpcl-develop] DPCL on x86-64

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

Assuming Dyninst uses __x86_64, use that. The only other define that looks 
like it makes sense is __x86_64__, and I don't see any other reason for 
choosing one over the other except for what the Dyninst code uses now.

This should be used only for changes specific to the processor's 
instruction set, as was done with lock.c for ia64. Anything that is a 64 
bit specific change unrelated to  implementing support for this specific 
processor should still use the __64_BIT define unless we find problems 
with that.

Dave





Jim Galarowicz <je...@sg...> 
Sent by: dpc...@li...
04/11/2005 01:44 PM

To
Dave Wootton/Poughkeepsie/IBM@IBMUS
cc
Steve Collins <sl...@sg...>, dpc...@li..., 
per...@sg...
Subject
Re: [Dpcl-develop] DPCL on x86-64






Dave, Steve,

This is "cpp -dM test.c" output from an EM64T machine:

jeg/perftools> touch test.c
jeg/perftools> cpp -dM test.c
#define __athlon_sse__ 1
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define unix 1
#define __x86_64 1
#define __SIZE_TYPE__ long unsigned int
#define __ELF__ 1
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __SSE_MATH__ 1
#define __athlon 1
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __x86_64__ 1
#define __linux 1
#define __unix 1
#define __LDBL_MAX_EXP__ 16384
#define __LONG_MAX__ 9223372036854775807L
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __DBL_DIG__ 15
#define __USER_LABEL_PREFIX__
#define linux 1
#define __STDC_HOSTED__ 1
#define __SSE2__ 1
#define __LDBL_MANT_DIG__ 64
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __WCHAR_TYPE__ int
#define __FLT_DIG__ 6
#define __FLT_MAX_10_EXP__ 38
#define __INT_MAX__ 2147483647
#define __amd64__ 1
#define __gnu_linux__ 1
#define __FLT_MAX_EXP__ 128
#define __DECIMAL_DIG__ 21
#define __DBL_MANT_DIG__ 53
#define __WINT_TYPE__ unsigned int
#define __SSE__ 1
#define __MMX__ 1
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define _LP64 1
#define __DBL_MAX__ 1.7976931348623157e+308
#define __tune_k8__ 1
#define __DBL_MAX_EXP__ 1024
#define __SSE2_MATH__ 1
#define __amd64 1
#define __athlon__ 1
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __FLT_MAX__ 3.40282347e+38F
#define __GXX_ABI_VERSION 102
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __DBL_MIN__ 2.2250738585072014e-308
#define __PTRDIFF_TYPE__ long int
#define __LP64__ 1
#define __LDBL_MIN_10_EXP__ (-4931)
#define __REGISTER_PREFIX__
#define __LDBL_DIG__ 18
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "3.3.3 (SuSE Linux)"

Thanks,
Jim G.


Dave Wootton wrote:

>Steve
>The preprocessor should have a set of standard defines built in, one or 
>more of which is specific to the hardware platform. Can you run the 
>command 'cpp -dM test.c' where test.c can be any source file, even an 
>empty file, and provide the output?
>
>Dave
>
>
>
>Steve Collins <sl...@sg...> 
>Sent by: dpc...@li...
>04/11/2005 01:17 PM
>
>To
>dpc...@li...
>cc
>per...@sg..., je...@sg...
>Subject
>[Dpcl-develop] DPCL on x86-64
>
>
>
>
>
>
>
>  In the near future the Open/SpeedShop project will be required to run 
on 
>the
>Opteron/EM64T architecture. This will require a #define specific to that 
>hardware.
>None of the approved list of #defines (ia64, __64BIT__) work AFAICT. 
>Suggestions
>from those 'in authority' are welcome.
>
>                                             Thanks - SteveC, SGI 
>Compilers/Tools
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Dpcl-develop mailing list
>Dpc...@li...
>https://lists.sourceforge.net/lists/listinfo/dpcl-develop
>
> 
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Dpcl-develop mailing list
Dpc...@li...
https://lists.sourceforge.net/lists/listinfo/dpcl-develop

Re: [Dpcl-develop] DPCL on x86-64

[Jeff H. <hol...@cs...>]

Jim Galarowicz wrote:

> Dave, Steve,
> 
> This is "cpp -dM test.c" output from an EM64T machine:
> 

I think we are using __x86_64 for Dyninst which is also what GNU
uses for its tag (x86_64-redhat-linux on our red hat machine).

This is designed to be common to AMD and Inetl's 64-bit versions
of x86.

Jeff

Re: [Dpcl-develop] DPCL on x86-64

[Jim G. <je...@sg...>]

Dave, Steve,

This is "cpp -dM test.c" output from an EM64T machine:

jeg/perftools> touch test.c
jeg/perftools> cpp -dM test.c
#define __athlon_sse__ 1
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define unix 1
#define __x86_64 1
#define __SIZE_TYPE__ long unsigned int
#define __ELF__ 1
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __SSE_MATH__ 1
#define __athlon 1
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __x86_64__ 1
#define __linux 1
#define __unix 1
#define __LDBL_MAX_EXP__ 16384
#define __LONG_MAX__ 9223372036854775807L
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __DBL_DIG__ 15
#define __USER_LABEL_PREFIX__
#define linux 1
#define __STDC_HOSTED__ 1
#define __SSE2__ 1
#define __LDBL_MANT_DIG__ 64
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __WCHAR_TYPE__ int
#define __FLT_DIG__ 6
#define __FLT_MAX_10_EXP__ 38
#define __INT_MAX__ 2147483647
#define __amd64__ 1
#define __gnu_linux__ 1
#define __FLT_MAX_EXP__ 128
#define __DECIMAL_DIG__ 21
#define __DBL_MANT_DIG__ 53
#define __WINT_TYPE__ unsigned int
#define __SSE__ 1
#define __MMX__ 1
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define _LP64 1
#define __DBL_MAX__ 1.7976931348623157e+308
#define __tune_k8__ 1
#define __DBL_MAX_EXP__ 1024
#define __SSE2_MATH__ 1
#define __amd64 1
#define __athlon__ 1
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __FLT_MAX__ 3.40282347e+38F
#define __GXX_ABI_VERSION 102
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __DBL_MIN__ 2.2250738585072014e-308
#define __PTRDIFF_TYPE__ long int
#define __LP64__ 1
#define __LDBL_MIN_10_EXP__ (-4931)
#define __REGISTER_PREFIX__
#define __LDBL_DIG__ 18
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "3.3.3 (SuSE Linux)"

Thanks,
Jim G.


Dave Wootton wrote:

>Steve
>The preprocessor should have a set of standard defines built in, one or 
>more of which is specific to the hardware platform. Can you run the 
>command 'cpp -dM test.c' where test.c can be any source file, even an 
>empty file, and provide the output?
>
>Dave
>
>
>
>Steve Collins <sl...@sg...> 
>Sent by: dpc...@li...
>04/11/2005 01:17 PM
>
>To
>dpc...@li...
>cc
>per...@sg..., je...@sg...
>Subject
>[Dpcl-develop] DPCL on x86-64
>
>
>
>
>
>
>
>  In the near future the Open/SpeedShop project will be required to run on 
>the
>Opteron/EM64T architecture. This will require a #define specific to that 
>hardware.
>None of the approved list of #defines (ia64, __64BIT__) work AFAICT. 
>Suggestions
>from those 'in authority' are welcome.
>
>                                             Thanks - SteveC, SGI 
>Compilers/Tools
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Dpcl-develop mailing list
>Dpc...@li...
>https://lists.sourceforge.net/lists/listinfo/dpcl-develop
>
>  
>

Re: [Dpcl-develop] DPCL on x86-64

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

Steve
The preprocessor should have a set of standard defines built in, one or 
more of which is specific to the hardware platform. Can you run the 
command 'cpp -dM test.c' where test.c can be any source file, even an 
empty file, and provide the output?

Dave



Steve Collins <sl...@sg...> 
Sent by: dpc...@li...
04/11/2005 01:17 PM

To
dpc...@li...
cc
per...@sg..., je...@sg...
Subject
[Dpcl-develop] DPCL on x86-64







  In the near future the Open/SpeedShop project will be required to run on 
the
Opteron/EM64T architecture. This will require a #define specific to that 
hardware.
None of the approved list of #defines (ia64, __64BIT__) work AFAICT. 
Suggestions
from those 'in authority' are welcome.

                                             Thanks - SteveC, SGI 
Compilers/Tools


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Dpcl-develop mailing list
Dpc...@li...
https://lists.sourceforge.net/lists/listinfo/dpcl-develop

[Dpcl-develop] DPCL on x86-64

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

  In the near future the Open/SpeedShop project will be required to run on the
Opteron/EM64T architecture. This will require a #define specific to that hardware.
None of the approved list of #defines (ia64, __64BIT__) work AFAICT. Suggestions
from those 'in authority' are welcome.

                                             Thanks - SteveC, SGI Compilers/Tools

[Dpcl-develop] re: bcreate use of stdout/stderr callbacks

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

    Mystery solved. Dyninst allows for redirecting stdout/stderr when
  forking the mutatee, but currently discards the two parameters passed in
  for that purpose. I'm working with Drew Bernat at UW-Madison on a Dyninst
  'adjustment'. Thanks to Dave for verifying this feature works on a non-Hybrid
  DPCL.

                                                SteveC - SGI Compilers/Tools

[Dpcl-develop] Re: bcreate - stdin and stdout

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

   Many thanks to DaveW for his testcase on this issue. Unfortunately
 it doesn't work with the Hybrid implementation. The 'bstart' is done and
 then things just sit in a 'zombie state'. Obviously somebody is waiting for
 some sort of signal, but nobody is accumulating cpu time - not dpclSD, not dpcld,
 not the mutator, not even hello. Of course I suspect that Dyninst is mucking
 things up somewhere, somehow. We have resources at UW-Madison that can help
 us out, once I am able to sharpen the focus on just where the problem lies.
 Right now I'm a little blurry-eyed. Not unusual for me though with one giant
 (DPCL) pitted against another giant (Dyninst). I need about 3 of myself right
 now - do a little parallel processing I guess. 

   Thanks Dave, as always, for your rapid and helpful response. I'll get back
 to you when my bleary-eyed state resolves itself.

                                                SteveC - SGI Compilers/Tools

Re: [Dpcl-develop] bcreate - stdout and stdin callbacks

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

Steve
I wrote a simple DPCL client that creates an instance of the 'hello' 
sample. The hello sample just prints '.' to stdout forever. When the 
client is run, the stdout output is sent to the stdout callback I 
established and not to any file. This works with the Linux BPatch 
implementation. Can you try this with the dyninst implementation to see if 
it works? if not, it seems something is going on within dyninst to affect 
this.

Dave

#include <dpcl.h>
#include <stdio.h>

void stdout_cb(GCBSysType sys, GCBTagType tag, GCBObjType obj, GCBMsgType 
msg)
{
  printf("stdout received %s\n", msg);
}

void stderr_cb(GCBSysType sys, GCBTagType tag, GCBObjType obj, GCBMsgType 
msg)
{
  printf("stderr received %s\n", msg);
}

int main(int argc, char *argv[])
{
  AisStatus sts;
  Process *p;

  Ais_initialize();
  p = new Process();
  sts = p->bcreate("netfin06", "/home/wootton/test/samples/hello/hello", 
// <-- Change these to match your system and target path
                   NULL, NULL, stdout_cb, (void *) 1, stderr_cb, (void *) 
2);
  if (sts.status() == ASC_success) {
    p->bstart();
  }
  else {
    printf("Create failed: %s\n", sts.status_name());
  }
  Ais_main_loop();
}



Steve Collins <sl...@sg...> 
Sent by: dpc...@li...
02/25/2005 02:20 PM

To
dpc...@li...
cc
sl...@sg...
Subject
[Dpcl-develop] bcreate - stdout and stdin callbacks







     Greetings, everyone. The Open/SpeedShop project at SGI has come
  across a <perceived> problem with the ability to specify callbacks
  for 'stdout' and 'stderr' at the time of 'bcreating' a new mutatee.
  Despite our best efforts, it appears that both stdout and stderr
  are redirected to 'dpcl.nnn.stdout' and 'dpcl.nnn.stderr' files. What
  we <think> we would like to see if we specify ONLY callback functions
  in the mutator for both stderr and stdout, and we do NOT specify any
  remote filenames, is that the mutator will be fed stdout I/O from
  the mutatee into its specified function entry point (e.g. stdout_cb)
  and stderr I/O from the mutatee into its specified callback function
  in the mutator (e.g. stderr_cb). The code in ProcessD::create, however,
  only seems to 'pipe' things into existing <dpcld> fd's for stdout
  and stderr (i.e. the dpcl.nnn.stdout/stderr files). AFAICT there is
  not attempt to build messages to the mutator(client) consisting of
  the mutatee's stdout or stderr output, whichever is in play.
     Are we (SGI) misreading the capabilities of this 'bcreate'
  feature? It might very well be the case that the Hybrid changes
  foul things up because we have already seen one instance of that
  occurring with <dpcld> termination messages.
     Clues welcome. My clueless DPCL state continues......

                                         SteveC - SGI Compilers/Tools


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Dpcl-develop mailing list
Dpc...@li...
https://lists.sourceforge.net/lists/listinfo/dpcl-develop

[Dpcl-develop] bcreate - stdout and stdin callbacks

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

     Greetings, everyone. The Open/SpeedShop project at SGI has come
  across a <perceived> problem with the ability to specify callbacks
  for 'stdout' and 'stderr' at the time of 'bcreating' a new mutatee.
  Despite our best efforts, it appears that both stdout and stderr
  are redirected to 'dpcl.nnn.stdout' and 'dpcl.nnn.stderr' files. What
  we <think> we would like to see if we specify ONLY callback functions
  in the mutator for both stderr and stdout, and we do NOT specify any
  remote filenames, is that the mutator will be fed stdout I/O from
  the mutatee into its specified function entry point (e.g. stdout_cb)
  and stderr I/O from the mutatee into its specified callback function
  in the mutator (e.g. stderr_cb). The code in ProcessD::create, however,
  only seems to 'pipe' things into existing <dpcld> fd's for stdout
  and stderr (i.e. the dpcl.nnn.stdout/stderr files). AFAICT there is
  not attempt to build messages to the mutator(client) consisting of
  the mutatee's stdout or stderr output, whichever is in play.
     Are we (SGI) misreading the capabilities of this 'bcreate'
  feature? It might very well be the case that the Hybrid changes
  foul things up because we have already seen one instance of that
  occurring with <dpcld> termination messages.
     Clues welcome. My clueless DPCL state continues......

                                         SteveC - SGI Compilers/Tools

Re: [Dpcl-develop] runtime AIS_SHM_SIZE

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

Steve
There is no requirement that AIS_SHM_SIZE be a constant or that it be 
limited to 32MB. I picked this because this was the default  value on the 
i386 systems we had at the time.

If you have a way to determine a value at run time, there shouldn't be  a 
problem with the concept of dynamically determining the value. This has to 
be a Linux-specific change though, since we do have a 256MB shared memory 
limit in AIX. I'm not exactly sure of the semantics of 
/proc/sys/kernel/shmmax. If this is a per-request maximum, then using 
whatever it is set to is probably not a problem. If it nrepresents the 
maximum shared memory allocation for the entire system then you need to be 
careful that DPCL does not consume the entire allocation.

Dave



Steve Collins <sl...@sg...> 
Sent by: dpc...@li...
02/23/2005 01:28 PM

To
dpc...@li...
cc

Subject
[Dpcl-develop] runtime AIS_SHM_SIZE







    Hello everyone -

         I'm trying out the new mailing list to see if I'll get
      it right. 
         As part of the Open/SpeedShop Project at SGI, one of our
      government parters (MartinS at LLNL) has pointed out that the
      value of AIS_SHM_SIZE really needs to be computed at runtime to
      be accurate. Martin suggests querying the system via /proc and
      a sysctrl call. I think Martin is dead-on, but I have no feel
      for the code change that might be best. The current non-AIX
      value of 0x01000000 seems small for an ia64 architecture.
         Comments anyone?

                                             SteveC -

                                             SGI Compilers/Tools


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Dpcl-develop mailing list
Dpc...@li...
https://lists.sourceforge.net/lists/listinfo/dpcl-develop

[Dpcl-develop] runtime AIS_SHM_SIZE

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

    Hello everyone -

         I'm trying out the new mailing list to see if I'll get
      it right. 
         As part of the Open/SpeedShop Project at SGI, one of our
      government parters (MartinS at LLNL) has pointed out that the
      value of AIS_SHM_SIZE really needs to be computed at runtime to
      be accurate. Martin suggests querying the system via /proc and
      a sysctrl call. I think Martin is dead-on, but I have no feel
      for the code change that might be best. The current non-AIX
      value of 0x01000000 seems small for an ia64 architecture.
         Comments anyone?

                                             SteveC -

                                             SGI Compilers/Tools

Re: [Dpcl-develop] Inclusion of UMD Dyninst Code?

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

Chip,
We have not incorporated the code yet. We have been held up by several 
issues, the latest being the move to SourceForge. Now that the move is 
complete, we are assesing what it would take to get this work done.

Dave



"David R. (Chip) Kent IV" <dr...@la...> 
Sent by: dpc...@li...
02/23/2005 08:52 AM

To
dpc...@li...
cc

Subject
[Dpcl-develop] Inclusion of UMD Dyninst Code?







Has the code from the University of Maryland, which incorporates the 
latest Dyninst into DPCL, been added to the CVS repository on sourceforge?

Chip


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Dpcl-develop mailing list
Dpc...@li...
https://lists.sourceforge.net/lists/listinfo/dpcl-develop

[Dpcl-develop] Inclusion of UMD Dyninst Code?

[David R. (C. K. I. <dr...@la...>]

Has the code from the University of Maryland, which incorporates the 
latest Dyninst into DPCL, been added to the CVS repository on sourceforge?

Chip

[Dpcl-develop] DPCL Open Source Project has moved to SourceForge

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

The DPCL Open Source Project has moved to SourceForge. The DPCL website 
can be accessed using the URL http://dpcl.sourceforge.net. The SourceForge 
project pages for the DPCL project can be accessed at 
http://sourceforge.net/projects/dpcl

All DPCL project content is now available from our new location. The 
following mailing lists are available for use

dpc...@li... for DPCL project announcements
dpc...@li... for general DPCL user questions
dpc...@li... for DPCL questions related to 
developing tools using DPCL or to DPCL enhancements.

Your existing subscriptions have been copied to the new mailing lists. 
Please update your address books to reference the new email addresses.

Dave

Re: [Dpcl-develop] STL and DPCL

[Albert F. <al...@us...>]

Steve,
I want to avoid STL in the public header, not in the source. A simple 
example is in the FunctionList.h.
The "void *_function_list" is really a vector <FunctionId*> pointer. the 
member function get_count() return the size of the vector, and the 
get_entry(int i) return the i'th entry of the FunctionId.

SourceObj.h is another example with reference count: It has nothing but a 
private variable "SourceObjABC * realSource", which points to the real 
implementation. This SourceObjABC should not appear in the public header 
(/usr/lpp/ppe.dpcl/include/* in aix).

The advantage of separate the interface and the implementation is that the 
tool writer needs not to recompile for each implementation (SourceObjABC) 
changes.

STL adds another layer of complication: compiler change. For the backward 
compatibility and support reason, we use an 'old' compiler version to 
create libdpcl.a. However, the tool writer can only access a 'new' version 
of compiler most of the time. STL may be enhanced by the newer compiler 
version.

If a public header has the following class:
   class A {
    public:
        int get_count() const {return v.size();}
        int get_entry(int i) const {if(i>=0 && i<v.size())return v[i]; 
else return -1;}
        int get_other() const {return other;}
        ...
    private:
        vector <int> v;
        int other;
    };

The dpcl library uses old STL to create an instances of A, but the call 
get_other() failed from tool writer if the "vector <int> v" changes size.

We can use a vector pointer to fix this problem, as below:
   class A {
    public:
        int get_count() const {return v->size();}
        int get_entry(int i) const {if(i>=0 && i<v->size())return (*v)[i]; 
else return -1;}
        int get_other() const {return other;}
        ...
    private:
        vector <int> * v;               <-- ptr
        int other;
    };

The inline functions get_count() and get_entry() can still fail as the 
size() and operator[] may point to wrong place in the new version of STL.

The only way to fix is to remove the inline functions to have the third 
form:

   class A {
    public:
        int get_count() const;
        int get_entry(int i) const;
        int get_other() const;
        ...
    private:
        vector <int> *v;
        int other;
    };

Now all the implementation are hidden in the libdpcl.a, which is compiled 
under the same version of STL. But, there is no need for the tool writer 
to know the private variable v is a STL vector* now. We reach the final 
form:
   class A {
    public:
        int get_count() const;
        int get_entry(int i) const;
        int get_other() const ;
        ...
    private:
        void * v;        <--- implementation detail
        int other;
    };

Albert Feng




Steve Collins <sl...@sg...> 
Sent by: dpc...@ww...
01/18/2005 09:44 AM

To
dpc...@ww...
cc
wd...@sg..., sl...@sg...
Subject
[Dpcl-develop] STL and DPCL






  Thanks to Albert Feng for pointing out past portability issues when 
using
  STL in the DPCL codes. He states that "We count(), get_xxxx() service 
functions to
  avoid the std:: at any cost". As a DPCL novice, this is a bit too vague 
for me.
  I was wondering if Albert (or anyone else) could give some specific 
examples of
  DPCL 'service functions' (precise source location in ~dpcl/src) and tell 
me just
  which STL functionality they replace. That way I can get an idea of just 
what
  would fit best as we implement our 'bget_all_statements' functionality 
for the
  ModuleObj level (only). Our originaly DPCL API change specified STL in a 
couple
  places and obviously we want to avoid going down the STL path if it has 
been a
  problem in the past.

                                                     Thanks again - 

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

[Dpcl-develop] STL and DPCL

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

  Thanks to Albert Feng for pointing out past portability issues when using
  STL in the DPCL codes. He states that "We count(), get_xxxx() service functions to
  avoid the std:: at any cost". As a DPCL novice, this is a bit too vague for me.
  I was wondering if Albert (or anyone else) could give some specific examples of
  DPCL 'service functions' (precise source location in ~dpcl/src) and tell me just
  which STL functionality they replace. That way I can get an idea of just what
  would fit best as we implement our 'bget_all_statements' functionality for the
  ModuleObj level (only). Our originaly DPCL API change specified STL in a couple
  places and obviously we want to avoid going down the STL path if it has been a
  problem in the past.

                                                     Thanks again - 

                                                      SteveC - SGI Tools

Re: [Dpcl-develop] Re: SOT_statment source type

[Albert F. <al...@us...>]

Steve, 

I don't have comments on the context of the SOT_statment, but we were 
burned before by the std:: templates in the library header.

The problem is that the libdpcl.a and the tool writer may use different 
version of compiler, which means the imprementation of std library may 
change (and it did change before)

We use count(), get_xxxx() service functions to avoid the std:: at any 
cost.

Albert Feng




Steve Collins <sl...@sg...> 
Sent by: dpc...@ww...
01/14/2005 04:22 PM

To
dpc...@ww...
cc
sl...@sg...
Subject
[Dpcl-develop] Re: SOT_statment source type







   Actually, upon further review (a football thing), I think John Robb's
 idea to parallel 'get_function_list' is the way to go. Bill Hachfeld of 
 SGI will be writing the DPCL 'mutator' that will use this new 
functionality
 and he proposes an addition to the DPCL API ('bget_all_statements) that 
would
 be implemented only at the ModuleObj level and starts in SourceObj.h as 
follows:

> > 
/*******************************************************************************
> >  * Changes for "dpcl/src/lib/include/SourceObj.h"
> > 
******************************************************************************/
> > 
> > class SourceObj
> > {
> > 
> > public:
> > 
> >     /**
> >      * Statement information.
> >      *
> >      * Structure describing a single source statement. Provides the 
source file
> >      * name, line number, column number, and address ranges of the 
statement.
> >      *
> >      * @note    If it is too difficult to combine disjoint address 
ranges for a
> >      *          single source statement in the DPCL communication 
daemon, you
> >      *          can generate multiple StatementInfo, one for each 
disjoint
> >      *          address range, and I can combine them in the 
framework.
> >      */
> >     struct StatementInfo {
> >     std::string file;  /**< Source file name. */
> >     int line;          /**< Source line number. */
> >     int column;        /**< Source column number. */
> > 
> >     /** List of address ranges (start/end). */
> >     std::vector< std::pair<AisAddress, AisAddress> > ranges;
> > 
> >     };
> > 
> >     /**
> >      * Get all statements.
> >      *
> >      * Blocking request to get all of the source statement information 
for this
> >      * module. 
> >      *
> >      * @param process    Process in which the module is located.
> >      * @param result     List of statement information for this 
module.
> >      * @return           Status of the request.
> >      */ 
> >     AisStatus bget_all_statements(const Process& process,
> >                               std::vector<LineInfo>& result);
> > 
> > 

    Comments more than welcome.

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