Skip to content

hdbg arm64 implementation proposal. #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 20 additions & 7 deletions heap.c
Original file line number Diff line number Diff line change
Expand Up @@ -344,13 +344,7 @@ getframe(void ***bp, void ***ip) {
"ret;"
);
}
#elif defined(__aarch64__) || defined(__arm__)
void
getframe(void ***bp, void ***ip) {
//XXX: TODO: support aarch64
}
#else

#elif defined(__i386__)
static void __attribute__((naked,noinline,optimize("O0")))
getframe(void ***bp, void ***ip) {
asm("mov (%esp), %ecx;"
Expand All @@ -360,6 +354,25 @@ getframe(void ***bp, void ***ip) {
"mov %ebp, (%edx);"
"ret;");
}
#elif defined(__aarch64__)
static void __attribute__((noinline,optimize("O0")))
getframe(void ***bp, void ***ip) {
void *stackp, *framep;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My version and (lack of) documentation for i386 and x86_64 were not a great example to follow here, but the idea of this function is to return both the instruction pointer (not stack pointer), and the frame pointer.

For aarch64, the frame pointer is indeed x29, and you can use the link register, x30, to get the caller's IP. They should really come from the same "frame", though - that's why I had the naked attribute on the x86 versions.

I'm not an ARM expert by any stretch, but it's possible that for leaf functions, the you can just use x29 directly, assuming it doesn't get manipulated in the prologue for "getframe" here. (i.e. I'm not sure if the lack of a naked attribute affects anything here - ISTR it isn't supported on aarch64.

Also, given you have given the output variables names, you might as well just assign the passed parameters from the output names in C, rather than doing it in asm.

I really need to add a test for this - I can do it tomorrow, but if you haven't worked it out, something like:

#include <stdlib.h>
int g(int i) { int *p = malloc(1024); *p = i; return i; }
int f(int i) { return g(i * 2);}
int main() { return f(42);}

Compiling with -fno-omit-frame-pointer and running

env LD_LIBRARY_PATH=libhdbg.so ./a.out
hdmp core

you should see the backtrace for the memory leak in the output.

Copy link
Author

@devnexen devnexen Aug 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For aarch64, the frame pointer is indeed x29, and you can use the link register, x30, to get the caller's IP.

My bad I misread.

They should really come from the same "frame", though - that's why I had the naked attribute on the x86 versions.

I guess, if we are to use inline assembly, we can strip down to just to something like this:

static void __attribute__((naked,noinline)) getframe(void ***bp, void ***ip) { asm( "mov x29, x0;" "mov x30, x1;" "ret;" ); }

otherwise no point using variables as I did indeed.

I won t be able to come back to it until wednesday..

asm(
"mov %0, sp;"
"mov %1, x29;"
"str %0, [%2];"
"str %1, [%3]"
: "=r"(stackp), "=r"(framep)
: "r"(ip), "r"(bp)
: "memory"
);
}
#else
void
getframe(void ***bp, void ***ip) {
//XXX: TODO: support other relevant archs
}
#endif

static void getstacktrace(void **ents, int max_ents) {
Expand Down