Re: [DynInst_API:] ProcControlAPI and threaddb

[Matthew LeGendre <legendre1@xxxxxxxx>]

On Mon, 6 Jan 2014, E.Robbins wrote:
> 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 configure is failing because of a lack of thread_db, then there's 
probably just a small autoconf bug that needs fixing.  The 
'--without-threaddb' option is intended to work.  Most systems have 
thread_db, so that option probably doesn't get used much and may have some 
bugs.
> > 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.
For the BlueGene/Q port we didn't #ifdef out the 
proccontrol/stackwalker/dynProcess code.  We still build Dyninst with a 
working ProcControlAPI, it's only the top-level options to do dynamic 
instrumentation that are disabled.
To build a similar rewriter-only Dyninst on Haiku you'd need a 
ProcControlAPI that built.  It wouldn't necessarily need to work, just 
build enough so that the appropriate libraries can be loaded.
> (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.
I doubt ProcControlAPI would "just work" on a new OS.  My experience has 
been that OS's have a lot of variance in their debug interfaces, even if 
it's ptrace on the surface.  FreeBSD and Linux are both ptrace-based, but 
due to threading models and other issues there's almost nothing in common 
between the two ports (In fact, due to threading model similarity, I think 
the FreeBSD port has more code in common with the Windows port of 
ProcControlAPI than Linux).
Unless the Haiku people made an explicit effort to match Linux or 
FreeBSD's implementation of ptrace, it's probably not going to work out of 
the box.
> > 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).
Our experience was that even with a standard like ELF, each OS has its own 
stricter requirements on executables and libraries (such as alignment, 
ordering of sections, "optional" fields that are required, etc...).  It's 
possible Haiku might load Dyninst-produced binaries, and it's possible 
they might have some requirements on binaries Dyninst isn't meeting.
> > 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
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api