From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3468960441938438403==" MIME-Version: 1.0 From: Mark Wielaard To: elfutils-devel@lists.fedorahosted.org Subject: Re: Using dwfl to enumerate frames of current thread Date: Wed, 19 Aug 2015 15:10:32 +0200 Message-ID: <1439989832.3117.113.camel@bordewijk.wildebeest.org> In-Reply-To: 87k2srfpfo.fsf@smart-cactus.org --===============3468960441938438403== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2015-08-19 at 14:11 +0200, Ben Gamari wrote: > I am adding full DWARF unwinding-based backtrace support to the Glasgow > Haskell Compiler's (GHC) runtime system. GHC now emits DWARF information > in the object files it produces [1] and we would like to be able to > record full backtraces on both runtime system events and the user's > request. Nice. The [1] doesn't point anywhere though. > The goal here is to expose a function to the runtime system and user > programs allowing them to get a snapshot of the calling thread's current > call-stack. I don't want to push you away from using elfutils, but have you looked at gcc's libbacktrace? That seems to be made precisely for your use case (it is how gccgo provides call-stacks to the go runtime). https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dtree;f=3Dlibbacktrace;hb=3DHEAD > It seems that elfutils' current dwfl interfaces only allow > for extraction of frames from Core dumps (with dwfl_core_file_attach) > and ptrace'd processes (with dwfl_linux_proc_attach). > = > In principle, however, I can't see any reason why frames couldn't be > extracted from the current thread. Besides taking care to preserve the > registers at the out-set, it doesn't even seem that this should be = > terribly difficult. Am I missing something? Does the interface for this > exist and I have simply overlooked it? Does it not yet exist but is > merely waiting for someone to implement it? In general libdwfl functions are used mostly to introspect other processes. But theoretically you could also use them on "self". It is not a usecase that has come up yet though (or maybe people do and I just didn't hear about it). I do think it should be possible and maybe it already kind of works if you use dwfl_linux_proc_report and dwfl_linux_proc_attach with pid () as argument. Although I wouldn't be surprised if it would deadlock trying to ptrace itself. So the best thing would be to write specific Dwfl_Thread_Callbacks functions for "self". The only tricky part would be the set_initial_registers callback. Which should be possible with some arch specific assembler tricks. Cheers, Mark --===============3468960441938438403==--