Skip to content
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

GDB - Avoid reading common unmapped address from memory #775

Open
Vge0rge opened this issue Aug 19, 2024 · 0 comments
Open

GDB - Avoid reading common unmapped address from memory #775

Vge0rge opened this issue Aug 19, 2024 · 0 comments

Comments

@Vge0rge
Copy link

Vge0rge commented Aug 19, 2024

There are cases that the stack will hold unmapped addresses in memory because of non returning functions.

An example of this is TF-M and the common_sfn_thread function here:
https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/069455be098383bf96eab73e3ff8e0c66c60fa5a/secure_fw/partitions/lib/runtime/sfn_common_thread.c#L20C6-L20C23

The caller of this function has return type thrd_fn_t:
https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/beb7825332ac2184b972e71d297564854408bffd/secure_fw/spm/core/thread.h#L40

As a result of this GDB tries to access the address 0xFFFFFFFE since it exists in the stack as a return value. There are platforms which will result to a fault when reading invalid accesses like this.

To reproduce the behavior that I am saying you can try to build the hello_world sample of Zephyr for the nRF5340.
If you break at the function common_sfn_thread and you examine the stack you will see that GDB tries to access the address:
image

And in the log of gdb server we can see that this memory address is failed to get read:
image

We cannot filter out all the unmapped addresses but for commonly used return addresses like this is it possible to filter them out in GDB so that the call is not forwarded to the GDB server?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant