On 05/12/2017 03:16 PM, Mark W. Krentel wrote:
> Red Hat could do better by providing packages for later compilers.
We do provide newer compilers in the Developer Toolset. However, we
only added POWER support in DTS for RHEL7.
___
Dyninst-api mailing li
Branch: refs/heads/jistone/build32
Home: https://github.com/dyninst/dyninst
Commit: ba05f95f55cebdcb2578bb0eda79bd7adf9b9839
https://github.com/dyninst/dyninst/commit/ba05f95f55cebdcb2578bb0eda79bd7adf9b9839
Author: Josh Stone
Date: 2017-03-14 (Tue, 14 Mar 2017)
Changed
On 01/09/2017 09:22 AM, Bill Williams wrote:
> Just tagged the testsuite repository and published;
Thanks, that's good enough for me.
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
Yay, new release! Time to start using it in earnest. :)
Is there a corresponding testsuite source package? At least, 9.2 had
this on the GitHub release page.
On 12/22/2016 02:01 PM, Barton Miller wrote:
>
> ANNOUNCEMENT: Release 9.3 of
> Dy
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 80111056ea99daeac08bb211caa74734cd6394ac
https://github.com/dyninst/dyninst/commit/80111056ea99daeac08bb211caa74734cd6394ac
Author: Josh Stone
Date: 2016-11-18 (Fri, 18 Nov 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: f86e3c2ea2e9c8a11a13b42b2b60438c53e597b5
https://github.com/dyninst/dyninst/commit/f86e3c2ea2e9c8a11a13b42b2b60438c53e597b5
Author: Josh Stone
Date: 2016-11-29 (Tue, 29 Nov 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: f88802f0737f4cf2a684cb2528f2c3ae0addc393
https://github.com/dyninst/dyninst/commit/f88802f0737f4cf2a684cb2528f2c3ae0addc393
Author: Josh Stone
Date: 2016-11-16 (Wed, 16 Nov 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 1838c82e65ec244018c2892d725cac092621fa9b
https://github.com/dyninst/dyninst/commit/1838c82e65ec244018c2892d725cac092621fa9b
Author: Josh Stone
Date: 2016-11-04 (Fri, 04 Nov 2016)
Changed paths
On 10/26/2016 01:06 PM, Osborn, Justin D. wrote:
> Bill - so I had it set to -std=c++11, adding
> -D_GLIBCXX_USE_CXX11_ABI=0 got rid of some of the undefined
> references involving libstdc++11 stuff. (I have gcc 5.4.0 and
> apparently it is set to use the new ABI by default, but dyninst must
> have
seems not to be a terribly valuable form of backwards compatibility,
>> especially given that our only binary distribution at present is managed by
>> RedHat. :) If I'm wrong on that point, though, folks should speak up.
>>
>> In general I think I'd prefer to depr
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 5a8bf8e285a41f6dfc16e6460f777e146258f7d1
https://github.com/dyninst/dyninst/commit/5a8bf8e285a41f6dfc16e6460f777e146258f7d1
Author: Josh Stone
Date: 2016-08-31 (Wed, 31 Aug 2016)
Changed paths
7; nit mentioned below, and we can
keep thinking about it.
>
> From: Dyninst-api on behalf of Josh Stone
>
> Sent: Tuesday, August 30, 2016 4:32 PM
> To: dyninst-api@cs.wisc.edu
> Subject: Re: [DynInst_API:] RFC: require users to have C++
mit dff30ae88e36.
On 08/17/2016 11:47 AM, Josh Stone wrote:
> Dyninst already requires C++11 features to build itself, but maintains
> support for pre-C++11 in the public interface. This means for instance
> that we have to use std::tr1::unordered_map and boost::shared_ptr
> instead of
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 4ca18d9e66dd8f9ffd12ac8fcd3386127db8d182
https://github.com/dyninst/dyninst/commit/4ca18d9e66dd8f9ffd12ac8fcd3386127db8d182
Author: Josh Stone
Date: 2016-08-30 (Tue, 30 Aug 2016)
Changed paths
Branch: refs/heads/v9.2_patches
Home: https://github.com/dyninst/dyninst
Commit: 2ef16d80916233c55e2694af373adb69a863933c
https://github.com/dyninst/dyninst/commit/2ef16d80916233c55e2694af373adb69a863933c
Author: Josh Stone
Date: 2016-08-26 (Fri, 26 Aug 2016)
Changed paths
pefoley2/rose_fixes
Rose build fixes
Commit: 895d3fad7e59dc2096d8c74111a0606ee0b70a44
https://github.com/dyninst/dyninst/commit/895d3fad7e59dc2096d8c74111a0606ee0b70a44
Author: Josh Stone
Date: 2016-07-26 (Tue, 26 Jul 2016)
Changed paths:
M dataflowAPI/h/stackanalysis.h
Log Message:
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: a032945f8f2b090ca63a5984123797695b916151
https://github.com/dyninst/dyninst/commit/a032945f8f2b090ca63a5984123797695b916151
Author: Josh Stone
Date: 2016-08-26 (Fri, 26 Aug 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: dfa440eb1bb9220d6c323fa34bc8f61c25928224
https://github.com/dyninst/dyninst/commit/dfa440eb1bb9220d6c323fa34bc8f61c25928224
Author: Josh Stone
Date: 2016-08-18 (Thu, 18 Aug 2016)
Changed paths
Dyninst already requires C++11 features to build itself, but maintains
support for pre-C++11 in the public interface. This means for instance
that we have to use std::tr1::unordered_map and boost::shared_ptr
instead of the C++11 std::unordered_map and std::shared_ptr.
For a small example motivati
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: b8596ad4023ec40ac07e669ff8ea3ec06e262703
https://github.com/dyninst/dyninst/commit/b8596ad4023ec40ac07e669ff8ea3ec06e262703
Author: Josh Stone
Date: 2016-08-09 (Tue, 09 Aug 2016)
Changed paths
Branch: refs/heads/v9.2_patches
Home: https://github.com/dyninst/dyninst
Commit: 90e1517732042e246286cbd248acb0a9f53a2c13
https://github.com/dyninst/dyninst/commit/90e1517732042e246286cbd248acb0a9f53a2c13
Author: Josh Stone
Date: 2016-08-09 (Tue, 09 Aug 2016)
Changed paths
ommit/4131cc518568ba7921428d801aa7e15876b1e03e
Author: Josh Stone
Date: 2016-08-03 (Wed, 03 Aug 2016)
Changed paths:
M dataflowAPI/src/liveness.C
Log Message:
---
Merge pull request #141 from dyninst/release9.2/fixes/liveness-asserts
Added asserts in liveness.C to prevent buffer under
#114
Commit: 6cca9d0ee6a4676028e511e2c5384ed959b1816f
https://github.com/dyninst/dyninst/commit/6cca9d0ee6a4676028e511e2c5384ed959b1816f
Author: Josh Stone
Date: 2016-08-03 (Wed, 03 Aug 2016)
Changed paths:
M common/h/dyn_regs.h
M dataflowAPI/src/RegisterMap.C
M datafl
o either stop
using a global BPatch or be sure to detach the process before exiting.
[1] https://www-auth.cs.wisc.edu/lists/dyninst-api/2014/msg00180.shtml
> Best,
> Martijn
>
>
> On Jul 27, 2016 18:48, "Josh Stone" <mailto:jist...@redhat.com>> wrote:
>
&g
On 07/27/2016 01:56 AM, Martijn wrote:
> Hello,
>
> I am trying to use proc->oneTimeCode inside an exit callback. The one
> time code adds a function call to finalize stuff in my instrumentation
> library.
>
> The exit callback nicely gets called at the end of the mutee, but the
> oneTimeCode doe
Branch: refs/heads/v9.2_patches
Home: https://github.com/dyninst/dyninst
Commit: 3728268bfa602902b4965de03001550843c3607a
https://github.com/dyninst/dyninst/commit/3728268bfa602902b4965de03001550843c3607a
Author: Josh Stone
Date: 2016-07-26 (Tue, 26 Jul 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 895d3fad7e59dc2096d8c74111a0606ee0b70a44
https://github.com/dyninst/dyninst/commit/895d3fad7e59dc2096d8c74111a0606ee0b70a44
Author: Josh Stone
Date: 2016-07-26 (Tue, 26 Jul 2016)
Changed paths
On 06/24/2016 10:10 AM, Bill Williams wrote:
> Folks--
>
> As any of you who've worked on (or with) proccontrol know, it's a
> complex beast. (If you don't know, Bart and I will be happy to tell war
> stories over beer...) One of the particular areas of complexity is
> stopping a process in ord
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: d1b4334e13e7cc4a3ee52a34c9d3f63ebff129b2
https://github.com/dyninst/dyninst/commit/d1b4334e13e7cc4a3ee52a34c9d3f63ebff129b2
Author: Josh Stone
Date: 2016-06-17 (Fri, 17 Jun 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 73cd0019856eca0636e652e402f9eaed6ba9dc61
https://github.com/dyninst/dyninst/commit/73cd0019856eca0636e652e402f9eaed6ba9dc61
Author: Josh Stone
Date: 2016-06-17 (Fri, 17 Jun 2016)
Changed paths
Branch: refs/heads/master
Home: https://github.com/dyninst/dyninst
Commit: 030131678e0b616573acc93fa1259d415b33765b
https://github.com/dyninst/dyninst/commit/030131678e0b616573acc93fa1259d415b33765b
Author: Josh Stone
Date: 2016-06-13 (Mon, 13 Jun 2016)
Changed paths
On 05/06/2016 01:21 PM, Jeff Hollingsworth wrote:
> I agree this makes sense to have as one repo. The exact why it was
> split is long ago lost to me.
>
> I don't think the source tar ball size is an issue. I also think
> merging the cmake is a good longer term goal.
>
> The only thing that
How would folks feel about pulling the dyninst testsuite back into the
main dyninst repository?
I mentioned in a conversation about CI on github[1]. Having them in
separate repos makes it harder to configure a lot of those CI tools.
Any breaking API changes have to be pushed separately, inevitabl
I have pushed this to master and v9.2.x.
Are notifications like this still desired?
On 04/28/2016 01:42 PM, Josh Stone wrote:
> GCC 5 made several ABI changes for C++11 support, but they also kept
> support for the older ABI. The macro _GLIBCXX_USE_CXX11_ABI can force
> which mode yo
On 04/29/2016 12:35 PM, John Detter wrote:
> Josh,
>
> This was an issue we were seeing with an earlier build of Dyninst. The
> issue was patched on the VEX branch and it should have been merged over
> to master. Do you think you could send me the binary that you are trying
> to parse?
It is l
On 04/28/2016 06:30 PM, Bill Williams wrote:
> I thought that was fixed on master, but it may not have made it over
> from VEX. Known, and a trivial fix.
Guess I should have sent a quick note before digging in...
I can't see what trivial fix you're expecting though. The assertion I
mentioned sti
Working with Dyninst master, I'm getting a "Bad addressing mode!"
assertion failed in ia32_decode_operands, parsing F23 libm.so,
specifically from glibc-2.22-11.fc23.x86_64. I do have the debuginfo
package for this installed too.
The assertion fails in the default case for switch(op.admet), becau
On 04/28/2016 01:42 PM, Josh Stone wrote:
> GCC 5 made several ABI changes for C++11 support, but they also kept
> support for the older ABI. The macro _GLIBCXX_USE_CXX11_ABI can force
> which mode you compile against.
Note also, this ABI toggling occurs regardless of using a -std=c++11
GCC 5 made several ABI changes for C++11 support, but they also kept
support for the older ABI. The macro _GLIBCXX_USE_CXX11_ABI can force
which mode you compile against.
Fedora 22 shipped with GCC 5 configured to use the old ABI by default,
as if -D_GLIBCXX_USE_CXX11_ABI=0, and Fedora 23 moved t
On 04/28/2016 12:35 PM, Peter Foley wrote:
> On Thu, Apr 28, 2016 at 1:19 PM, Sunny Shah wrote:
>> Peter,
>>
>> The XML files are not publicly available - they're accessible to a very
>> small group of people at UW.
>>
>> Thanks,
>> Sunny
>
> Ok. Maybe you should add a comment to the script to th
On 04/25/2016 10:58 AM, Bill Williams wrote:
> I think what we want to maintain, at least for 9.x, is the following
> guidelines:
>
> * No "using namespace" in public headers (foo/h/*.h); "using foo::bar"
> may be used but prefer typedefs if you want to clean up overly long
> namespace chains
>
On 04/23/2016 12:57 PM, Peter Foley wrote:
> Don't unconditionally include all of namespace std
I agree it's good practice avoid "using namespace std;" in API headers,
so you don't force that on the library's users.
However, IMO removing std from all the source files is needless churn.
It's perfe
On 01/13/2016 11:55 AM, Jim Galarowicz wrote:
>
> On 01/13/2016 09:49 AM, Josh Stone wrote:
>> On 01/13/2016 08:40 AM, Jim Galarowicz wrote:
>>> [ 10%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
>>> /nobackupnfs2/jgalarow/OpenSpeedShop_RO
On 01/13/2016 08:40 AM, Jim Galarowicz wrote:
> [ 10%] Building CXX object common/CMakeFiles/common.dir/src/linuxKludges.C.o
> /nobackupnfs2/jgalarow/OpenSpeedShop_ROOT/BUILD/maia112/dyninst-9.1.0/common/src/linuxKludges.C(1032):
> error: no instance of constructor "std::basic_ifstream<_CharT,
> _T
On 12/08/2015 09:14 AM, Bill Williams wrote:
> in the absence of any further showstoppers, this will become 9.1.0.
I'm still hoping dynamic library callbacks will change from modules to
objects, now that there can be many modules per dynamic library. I
mentioned this again when the change finally
On 10/22/2015 01:24 PM, Bill Williams wrote:
> On 10/22/2015 03:21 PM, Josh Stone wrote:
>> On 10/22/2015 11:58 AM, Bill Williams wrote:
>>> Reorganized Monday's commits into 9.0.x (everything but the module
>>> changes) and 9.1.x (module changes only, thus far
On 10/22/2015 11:58 AM, Bill Williams wrote:
> Reorganized Monday's commits into 9.0.x (everything but the module
> changes) and 9.1.x (module changes only, thus far) branches. They'll
> both get merged back to master post-releases.
Better, thanks!
There's one more break that snuck into v9.0.x:
On 10/19/2015 02:43 PM, Bill Williams wrote:
> * Shared libraries are now consistent with executables: .o files are
> modules/mapped_modules, and they are contained in objects/mapped_objects.
How are dynamic library callbacks working under this? We talked about
changing this to report BPatch_obj
On 09/17/2015 11:58 AM, Bill Williams wrote:
> For historical reasons, modules at the BPatch and Symtab levels have
> meant different things when applied to an executable (constituent .o
> files) and a shared library (one module for the library itself). There's
> no longer any good reason for th
On 09/11/2015 01:46 PM, Bill Williams wrote:
> How on earth does git archive not know how to tar.gz something? Is there
> no gzip (or no tar) on this system?
It's too old? This is first mentioned in git 1.7.7 relnotes. (Sep 2011)
___
Dyninst-api mailing
On 09/01/2015 07:23 AM, Xiaozhu Meng wrote:
> We have fixed the source tarball problem, and we are working with the
> Ubuntu package problem.
Sorry to keep nitpicking, but...
Can you correct the directory prefix? It's Dyninst-9.0.3/ -- whereas
the previous versions had DyninstAPI-9.0.2/ etc. I
On 08/28/2015 08:56 AM, Bill Williams wrote:
> Since I've gotten no further word on bugs since applying Josh's patch,
> I'm tagging 9.0.3 publicly. Website updates to follow.
I see 9.0.3 listed on the website, but the source tarballs are 404. I
see them in release9.0.2/ though, along with all th
happened there. On the
other hand, a few pc_*.stat_* mutatees showed up new.
That's all I've got. Sorry I didn't test this so detailed earlier, but
we'll get release polishing behind you soon enough...
>From 9b8817659d1de81048bf4302cd185b23c1607ac3 Mon Sep 17 00:00:00 2001
From
On 08/13/2015 09:07 AM, Bill Williams wrote:
> There are now targets for doc (build all latex manuals, check existence
> of Word-derived PDFs) and $COMPONENT-doc (same, but for an individual
> manual) for every component that has documentation. I've moved the
> authoritative versions of the word
I went through gcc5 warnings and cleaned up a few things that looked like
real bugs. The rest are mostly unused parameters and locals. I'll probably
wait until after the next release to go for warning-clean again.
I also did a Coverity run and fixed a few of the more obvious things.
dyninst:
b7
Hi,
On 08/05/2015 04:11 PM, Xiaozhu Meng wrote:
> 1. Update const qualifier for return values of some ParseAPI
> interfaces such as CodeObject::funcs().
> 2. Update LoopTreeNode namings
This commit included a change to parseAPI/src/Parser.C which is breaking
the build with a stray semicolon. I'm
On 07/31/2015 03:12 PM, Josh Stone wrote:
> On 07/31/2015 08:54 AM, Bill Williams wrote:
>> On 07/30/2015 05:28 PM, Josh Stone wrote:
>>> These syscalls can read/write entire blocks of memory in one syscall,
>>> rather than using a series of word-sized ptrace peek/pok
This patch is now on master.
On 07/30/2015 03:28 PM, Josh Stone wrote:
> This had a bug where a last_typed value was saved even for parameter
> includeTypes==false, where cplus_demangle opts lacked DMGL_PARAMS.
> Similarly, the nativeCompiler parameter wasn't considered at all
On 07/31/2015 08:54 AM, Bill Williams wrote:
> On 07/30/2015 05:28 PM, Josh Stone wrote:
>> These syscalls can read/write entire blocks of memory in one syscall,
>> rather than using a series of word-sized ptrace peek/poke requests.
>>
>> However, not all kernels ha
On 07/31/2015 08:53 AM, Bill Williams wrote:
> On 07/30/2015 05:28 PM, Josh Stone wrote:
>> This had a bug where a last_typed value was saved even for parameter
>> includeTypes==false, where cplus_demangle opts lacked DMGL_PARAMS.
>> Similarly, the nativeCompiler parameter was
These syscalls can read/write entire blocks of memory in one syscall,
rather than using a series of word-sized ptrace peek/poke requests.
However, not all kernels have these (ENOSYS), and they don't bypass page
protection (EFAULT), so the ptrace way is still required as a fallback.
---
common/src
This had a bug where a last_typed value was saved even for parameter
includeTypes==false, where cplus_demangle opts lacked DMGL_PARAMS.
Similarly, the nativeCompiler parameter wasn't considered at all for
caching.
This caused strange issues in boost::multi_index, where its internal
rehashing was s
With boost 1.58, the boost::bind() in Slicer::getPredecessors()
gave an "error: call of overloaded 'bind[...]' is ambiguous".
Every other bind in dyninst uses plain boost::bind(), which does its own
inspection of return type. That works well in this case too, even with
older boost versions.
For
On 06/02/2015 12:57 PM, Tony Zhang wrote:
> Hello,
>
> Is it possible to use DynInst from a different thread within a process?
> For example, a program would create multiple pthreads, and one of them
> (a master) then attempts to control the execution of all other threads
> in the program.
On Lin
On 03/25/2015 12:22 PM, Alexander Morris wrote:
> This commit fixes the handling of AL/AX in 8-bit unsigned multiplication
> for x86. Previously, both registers were marked as being written,
> leading to errors in symbolic evaluation. This commit no longer marks AL
> as written.
If I may make a su
On 02/18/2015 11:42 AM, Bill Williams wrote:
> On 02/18/2015 01:37 PM, Gerard wrote:
>> Ah ok, I didn't know that.
>>
>> About how reproducible is the error, I run it three times (without the
>> change you suggested) and every time stopped at around 32000 threads.
>> Now I added appProc->continueEx
On 02/17/2015 08:54 AM, Bill Williams wrote:
> On 02/17/2015 07:05 AM, Xi Chen wrote:
>> Hi,
>>I recently try to debug the dynamic mode dyninst because I found the
>> result is inconsistent with the static rewrite. I basically want to
>> attach to mutatee process, and see how the instrumentatio
On 02/13/2015 09:02 AM, Bill Williams wrote:
> On 02/13/2015 10:54 AM, Rakesh Kumar wrote:
>> Hi,
>>
>> I wanted to know if DynInst can be used to profile/instrument OS/kernel
>> code in additional to the user level code. What I want to do is get some
>> statistics, say hottest basic blocks, for an
On 02/03/2015 07:22 AM, Gerard wrote:
> Hello,
>
> I'm experiencing a strange issue while instrumenting a multithreaded
> application. In essence this application sends data to other processes
> through TCP/IP connections using multiple threads (one per connection).
> The problem is that after 39~
On 12/15/2014 03:19 PM, Sergej Proskurin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
>> On 15.12.2014 19:38, Josh Stone wrote:
>
>> Note that GCC may use builtin versions of some libc functions, and
>> make transformations for effi
On 12/15/2014 09:02 AM, Bill Williams wrote:
> On 12/14/2014 04:04 PM, Sergej Proskurin wrote:
>> Hello,
>>
>> currently, I am developing a software that should be able to rewrite
>> binaries (as the name suggests, the process of rewriting should be
>> performed statically). One of the goals I am t
On 11/25/2014 10:26 AM, Nathan McKain wrote:
> I am trying to use getSourceLines from BPatch_image, but the
> std::vector object is causing my compiler to
> complain. It says that it is either an invalid use of incomplete
> type, or a forward declaration error. Is there a specific kind of
> BPatch_
On 11/21/2014 01:02 AM, Adrian M Negreanu wrote:
> I tried to instrument a strip-ed chrome, as a workaround the
> processCreate issue(s) , only to find another problem, this time in
> image::findMain()
As a workaround, since you're the one stripping it, you can try
stripping slightly less. Just r
On 11/18/2014 08:40 AM, bill wrote:
> ...well, that's a problem. Really, that's two problems. I'll see what I
> can do about these, but it may take me a bit--I'm at SC this week.
>
> We're trying to parse the entire process at creation time in order to
> install pre-fork instrumentation. The att
On 10/17/2014 08:17 PM, Jim Galarowicz wrote:
> Hi Josh,
>
> Thanks for the reply. I haven't been able to figure anything out. This
> must be unique to Titan? It seems no one else has had this issue?
>
> I tried looking along the include path.
>
> 39%] Building CXX object
> dyninstAPI/CMa
On 10/17/2014 02:25 PM, Jim Galarowicz wrote:
> I'm not sure if the patchAPI compile options have the correct defines
> set or is there a compile option that is required to get the constants
> recognized?
> I put the #include stdint.h into BPatch.C to see if the Dyninst build
> was missing inclu
is at 0x3fffb1f6fffc. So
that appears to be the rewind issue, and a full BUG_DEFINES fixes it.
Reported-by: Michael Petlan
Signed-off-by: Josh Stone
---
cmake/cap_arch_def.cmake | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmake/cap_arch_def.cmake b/cmake
On 10/07/2014 04:39 PM, Matthew LeGendre wrote:
>
> On Tue, 7 Oct 2014, Josh Stone wrote:
>> I've been thinking about improving the selinux story -- right now we
>> must allow execmem/execstack because of the RWX memory maps. I'd like
>> to try separating this i
On 10/07/2014 09:26 AM, Bill Williams wrote:
> Two things here:
>
> 1) Dyninst 8.2.1 is coming soon, pending evaluation of fixes for a
> couple more bugs that have been reported in 8.2.0.
Please do push commits before the actual release, so interested parties
like myself may review the changes.
On 09/19/2014 01:59 PM, Bill Williams wrote:
>
>>> Questions:
>>>
>>> 1) Is there a specific motivating system for this, or just general code
>>> cleanup? My understanding of the evolution of the instruction set says
>>> that LAHF should be missing from a vanishingly rare set of processors.
>>
>>
On 09/19/2014 09:58 AM, Bill Williams wrote:
> On 09/18/2014 04:03 PM, Josh Stone wrote:
>> It was noted in Dyninst 7.0 known bugs that x86_64 CPUs which lacked
>> LAHF/SAHF would not be able to run instrumentation. This limitation
>> still holds in 8.x, even though it&
It was noted in Dyninst 7.0 known bugs that x86_64 CPUs which lacked
LAHF/SAHF would not be able to run instrumentation. This limitation
still holds in 8.x, even though it's no longer mentioned.
There was already one cpuid check for xmm capability. It's also
possible to check lahf_lm in cpuid 80
On 08/20/2014 10:23 AM, Fabian Mager wrote:
>
>> If you look at the variable locations of the parameters, they should
>> have address ranges attached to them, and you should be able to set
>> your breakpoint at the beginning of the valid range with no problem.
>
> Looking at the variable locati
On 07/22/2014 08:53 AM, Bill Williams wrote:
> As per Bud's request...this will become INSTALL fairly shortly. Comments
> and requests for clarification are appreciated.
I would also list what distro packages will satisfy dependencies, like:
Fedora & RHEL:
yum install cmake make gcc-c++ binu
When detaching from a process, it needs to be stopped to remove syscall
instrumentation. If it's not already, stop it first and continue after.
---
dyninstAPI/src/dynProcess.C | 17 +
1 file changed, 17 insertions(+)
diff --git a/dyninstAPI/src/dynProcess.C b/dyninstAPI/src/dynPr
I've had a fun time recently trying to nail down this bug. If a mutator
has its BPatch as a global variable, attaches to a mutatee, then exits
without explicitly detaching, the mutator will segfault.
This problem is easily avoided if your BPatch object has a tighter
scope, e.g. as a local in main
On 07/07/2014 07:32 PM, Francis Deslauriers wrote:
> Also, what is the purpose of the option RelWithDebInfo? Is there a
> place where I can more info on the different build options?
RelWithDebInfo is for release with debuginfo, just "-O2 -g" on gcc. You
can find this in dyninst/cmake/optimization
On 07/07/2014 02:44 PM, Francis Deslauriers wrote:
> Hi folks,
>
> I tried to attach a Firefox process and it took Dyninst ~35 seconds.
> My mutator program forks and the child process exec firefox with the
> -h argument.
>
> Here is a pastebin where I used the time command and DYNINST_DEBUG_STAR
- Include dynC_API in the list of versioned libraries.
- Define DYNC_EXPORT and use it for createSnippet.
---
CMakeLists.txt | 2 +-
dynC_API/CMakeLists.txt | 3 ++-
dynC_API/h/dynC.h | 30 +-
3 files changed, 24 insertions(+), 11 deletions(-)
diff --g
On 06/19/2014 11:34 AM, Jim Galarowicz wrote:
> Currently, I'm using the official release for 8.2.
That was my point - there's no such thing yet. The v8.2 branch is
currently in development towards a release, but it's not finished. I
expect the tag will be called v8.2.0 when it's official.
_
On 06/19/2014 11:15 AM, Matthew LeGendre wrote:
>
>
> On Thu, 19 Jun 2014, Josh Stone wrote:
>> On 06/19/2014 10:03 AM, Matthew LeGendre wrote:
>>>
>>> Jim,
>>>
>>> I believe this is a known issue that's fixed in the latest Dyninst 8.2
>
On 06/19/2014 10:03 AM, Matthew LeGendre wrote:
>
> Jim,
>
> I believe this is a known issue that's fixed in the latest Dyninst 8.2
> branch. It's an issue with certain cmake versions. You could update
> Dyninst, or I belive using this cmake install on rzmerl avoids the
> problem:
>
> /coll
On 06/18/2014 01:22 PM, Jim Galarowicz wrote:
> Hi all,
>
> I'm getting a build error on rzmerl at LLNL when trying to build the
> release version of 8.2.
>
> The message I'm getting:
>
> Linking CXX shared library libcommon.so
> /usr/bin/ld: cannot find -lLINK_PRIVATE
> collect2: ld returned 1
Now createInitialMappedObjects uses a fileDescriptor comparison too.
Reported-by: Francis Deslauriers
Signed-off-by: Josh Stone
---
dyninstAPI/src/dynProcess.C | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dyninstAPI/src/dynProcess.C b/dyninstAPI/src/dynProcess.C
index 9f11f54
On 05/21/2014 11:38 AM, Francis Deslauriers wrote:
> Hi,
>
> I am trying to understand how to use Dyninst with running processes. I
> wish to attach to a running process, instrument it, detach from it,
> let it run a bit and reattach to the same process.
>
> I can attach, instrument and detach wi
On 05/21/2014 12:20 PM, Bill Williams wrote:
> A virtuous patch, though I admit some confusion: I believe that the trap
> table variables should already be exported on the v8.2 branch...
Oh, I didn't say explicitly, but yes this patch and my others are for
the v8.2 branch.
I don't see any existi
With -fvisibility=hidden and rpm stripping, some of the symbols in
dyninstAPI_RT can't be found. This patch adds DLLEXPORT to every name
in the unstripped symbol table which is referenced by string "name" in
libdyninstAPI.so, hopefully allowing all necessary dynamic lookups.
---
dyninstAPI_RT/h/d
The file test6LS-x86.asm can only be compiled with nasm, but cmake was
trying GNU as. So enable ASM_NASM and set the PLATFORM define it wants.
CMake only gained NASM support in 2.8.4, so I've also copied those
supporting files. (with the appropriate license declarations)
---
CMakeLists.txt
On 05/16/2014 04:03 PM, Josh Stone wrote:
> +Mutex * Counter::locks = new Mutex[Counter::NumCounterTypes];
> int Counter::global_counts[Counter::NumCounterTypes];
FWIW, I considered ditching the mutexes and making global_counts[] use
atomic, but we don't yet live in a world wh
Previously, if process.C ran its destructors before generator.C, then
Counter::locks would be destroyed before int_cleanup. The latter is
responsible for ending the handler thread, which may still be trying to
adjust locks. Boost's mutex throws an exception if you try to acquire a
destroyed lock,
1 - 100 of 180 matches
Mail list logo
