Should the unwind functionality in callstack.c be moved to DR, or externalised?

18 views
Skip to first unread message

Greg Cawthorne

unread,
May 11, 2020, 4:42:00 AM5/11/20
to Dr. Memory Users
Hi all.

I am currently working on porting DrMemory to AArch64 over the next few months.

I have been progressing through fixing the build errors and have come to the 'is_retaddr' function on line 1040: DrMemory - callstack.c., which is used by the 'print_callstack' function.

I am wondering if this kind of functionality would be better off in DynamoRIO, or if we could somehow externalise this unwinding functionality (and perhaps other functionality), with a dependancy to another more comprehensively maintained project like llvm.

It seems 'is_retaddr' is checking the previously executed memory but doing arithmetic on the PC, but this isn't guaranteed to be safe as far as I can tell.

I can fix this particular build error in a similar way to what's already been done and continue on my path for now, but thought it might be a good conversation to start here.

All the best,
Greg Cawthorne.

Derek Bruening

unread,
May 11, 2020, 11:43:47 AM5/11/20
to drmemor...@googlegroups.com
Separating the callstack walking and callstack storage functionality into its own library is a longstanding feature goal: https://github.com/DynamoRIO/drmemory/issues/823 (and in the DR tracker
https://github.com/DynamoRIO/dynamorio/issues/2414).

Re: using other libraries instead: there are advantages but also disadvantages and sometimes blockers and careful evaluation is needed for feasibility.  Library usage in a client environment has transparency and resource limitations.  In the past we looked into switching to LLVM's encoder but concluded it was not feasible to separate it out and it was just not designed for runtime resource constrained usage.

Re: is_retaddr not being safe: if you could elaborate on what you mean there.  The dereferences of "pc - N" are all inside a DR_TRY_EXCEPT where faults are properly handled.

--

---
You received this message because you are subscribed to the Google Groups "Dr. Memory Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drmemory-users/c31f2af8-3f90-40b5-9af7-77d9f87874e7%40googlegroups.com.

Greg Cawthorne

unread,
May 12, 2020, 7:28:52 AM5/12/20
to Dr. Memory Users
Hi Derek.

Good to see this has already been considered.

Re: is_retaddr not being safe. It was just an observation that previous instructions might be junk, so perhaps safe is not the correct word, but rather more 'guaranteed to work'.

However this probably isn't a huge issue if it works most of the time.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemor...@googlegroups.com.

Derek Bruening

unread,
May 12, 2020, 11:13:57 AM5/12/20
to drmemor...@googlegroups.com
By its nature it has to be a heuristic with no guarantee.  Debug info is frequently not available (esp for system libraries) and callstacks are gathered so frequently in any case (to report allocation contexts, they have to be gathered on every malloc) that looking in debug info is generally prohibitively expensive.

To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drmemory-users/bb65fb84-af7d-4207-89c1-ad4cf10a9411%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages