Re: [DynInst_API:] ProcControlAPI and threaddb

["E.Robbins" <er209@xxxxxxxxxx>]

Thanks for the quick reply.
> ________________________________________
> From: Dyninst-api [dyninst-api-bounces@xxxxxxxxxxx] on behalf of bill [bill@xxxxxxxxxxx]
> Sent: 06 January 2014 16:42
> To: dyninst-api@xxxxxxxxxxx
> Subject: Re: [DynInst_API:] ProcControlAPI and threaddb
> 
> Ed--
> 
> Time for stupid questions: do you actually want Dyninst as a binary
> rewriter, or do you just want (e.g.) parseAPI?

I currently only use other bits of Dyninst (parseAPI, symtabAPI, instructionAPI etc), but ideally I'd like it all to work as all my work revolves around binary analysis and Dyninst is obviously great for that. I want to use haiku for my day-to-day work, but if I can't get it to play nice with dyninst then that wont be possible.

> 
> If you only want a subset of components, just build them ("make
> parseAPI", etc). 

You don't need configure first? (configure currently fails). I'll have a look.

> 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. 

I'll do that.

> 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. 

I guess so... but that sounds a lot of work, possibly more than just getting haiku supported in a standard way.

(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.)

If I can build without threaddb then maybe it will *just work*. Haiku has pthreads support, but I get the impression that dyninst expects to have more control over threads than that would provide. Aside from pthreads, it has it's own threading model.

> 
> 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. 

Not a clue about the runtime loader. It's probably pretty much the same as Linux (I know it uses slightly different env vars though, e.g. LD_LIBRARY_PATH is just LIBRARY_PATH on haiku).

> 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).

I ported both libelf and libdwarf to haiku a year or more ago, and have just updated them (haiku got package management recently). They basically just build. It is indeed an ELF/dwarf system using gcc, but though it has a gdb port it isn't really supported (they had to fork it a long time ago to get support), and doesn't have threaddb (haiku has it's own debugger).

Thanks again,
Ed