dpcl-develop Mailing List for Dynamic Probe Class Library
Brought to you by:
dpcl-admin,
dwootton
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(9) |
Aug
(1) |
Sep
(3) |
Oct
(5) |
Nov
(5) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(6) |
Jun
(4) |
Jul
(18) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(26) |
Dec
(31) |
2004 |
Jan
(14) |
Feb
(5) |
Mar
(6) |
Apr
(1) |
May
(4) |
Jun
(8) |
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(7) |
Dec
|
2005 |
Jan
(8) |
Feb
(8) |
Mar
(1) |
Apr
(6) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Accounts_Payable_Team <hi...@ct...> - 2024-05-15 09:27:50
|
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 |
From: M. Z. <mz...@tl...> - 2015-01-08 05:55:12
|
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 |
From: Dave W. <dwo...@us...> - 2007-10-31 20:35:29
|
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 |
From: Dave W. <dwo...@us...> - 2006-04-18 16:17:15
|
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 |
From: Dave W. <dwo...@us...> - 2005-08-10 00:13:34
|
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 |
From: Dave W. <dwo...@us...> - 2005-05-02 22:29:41
|
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 |
From: Steve C. <sl...@sg...> - 2005-05-02 15:34:32
|
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. > |
From: Dave W. <dwo...@us...> - 2005-04-13 15:17:20
|
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] |
From: Dave W. <dwo...@us...> - 2005-04-11 19:54:44
|
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 |
From: Jeff H. <hol...@cs...> - 2005-04-11 18:13:16
|
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 |
From: Jim G. <je...@sg...> - 2005-04-11 17:45:57
|
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 > > > |
From: Dave W. <dwo...@us...> - 2005-04-11 17:36:07
|
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 |
From: Steve C. <sl...@sg...> - 2005-04-11 17:18:12
|
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 |
From: Steve C. <sl...@sg...> - 2005-03-02 16:07:46
|
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 |
From: Steve C. <sl...@sg...> - 2005-02-28 17:43:10
|
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 |
From: Dave W. <dwo...@us...> - 2005-02-28 14:19:21
|
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 |
From: Steve C. <sl...@sg...> - 2005-02-25 19:20:32
|
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 |
From: Dave W. <dwo...@us...> - 2005-02-24 16:29:19
|
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 |
From: Steve C. <sl...@sg...> - 2005-02-23 18:28:12
|
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 |
From: Dave W. <dwo...@us...> - 2005-02-23 14:38:17
|
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 |
From: David R. (C. K. I. <dr...@la...> - 2005-02-23 13:53:00
|
Has the code from the University of Maryland, which incorporates the latest Dyninst into DPCL, been added to the CVS repository on sourceforge? Chip |
From: Dave W. <dwo...@us...> - 2005-02-22 16:32:40
|
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 |
From: Albert F. <al...@us...> - 2005-01-19 01:05:21
|
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 |
From: Steve C. <sl...@sg...> - 2005-01-18 17:44:49
|
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 |
From: Albert F. <al...@us...> - 2005-01-15 01:21:16
|
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 |