Re: [DynInst_API:] ProcControlAPI and threaddb

[bill <bill@xxxxxxxxxxx>]

Ed--

Time for stupid questions: do you actually want Dyninst as a binary 
rewriter, or do you just want (e.g.) parseAPI?
If you only want a subset of components, just build them ("make 
parseAPI", etc). If you want Dyninst as a binary rewriter, I believe 
what you're going to want to do is the same sort of thing we've done on 
BlueGene/Q (another rewriter-only platform). I would also highly 
recommend starting from git-head rather than from 8.1.2--we've upgraded 
our build system to CMake, and I expect it will be both easier to 
incorporate a new platform to start with, and less work in the long run 
to maintain, if you just hop on board now. Big picture, what you want is 
a libdyninstAPI that doesn't link against proccontrol/stackwalker, 
doesn't build any of the stack walking classes, and doesn't build the 
internal process classes (dynProcess/dynThread IIRC?). Anything that 
would create a BPatch level process or thread class would hand back an 
error (NULL and set error), etc. (Alternately, it might be worth the 
quick look to see whether haiku process control can be slotted into 
either the Linux or the BSD threading model and Just Plain Work--we 
should be able to build proccontrol without threaddb, and iirc that's 
fixed on git-head even if it's broken in 8.1.2.)
Other potential gotchas: I don't know whether the haiku loader places 
the same requirements on executables/shared libraries that the Linux 
loader does. In general, getting a rewritten binary to actually load 
correctly is the hard part of supporting rewriting on a new OS. I also 
don't know whether the libelf support on haiku is good, nor do I know 
whether libdwarf will work out of the box (it should, assuming a 
functional libelf). I am assuming ELF files are the default because 
there's a libelf port (and that seems silly if they're not).
--bw

On 2014-01-06 08:31, E.Robbins wrote:
> Hi,
> I am trying to build dyninst on haiku, which does not have threaddb.
> It is only needed by the process control api, which I don't need, so I
> am wondering if there's a way to build it without that. I've tried
> configure --without-threaddb but it still errors out complaining about
> missing thread_db.h. There doesn't seem to be a configure option to
> disable the process control api (and, I'd hoped, threaddb as well). Is
> there a way around this?
>
> Are there likely to be other problems I'll run into along the way?
>
> Thanks,
> Ed
>
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api