Exceptions not getting caught on bare-metal target

Hi,

We're working on adding exception handling support for a downstream bare-metal target. I read through the LLVM exception handling docs [1] and went through some patches from other backends to understand what parts we need to implement.

We're now at a point were it feels like it should work, but unfortunately exceptions are still not getting caught. Our target uses DWARF unwinding.

The problem seems to be that findFDE cannot find a CIE which covers the given PC. We're not sure why this is though. From [2] and other backend implementations we gathered that unw_getcontext saves the PC of the call-site, i.e. the return address of unw_getcontext and that is that we are doing as well.

Is there some other target hook in LLVM or libunwind that we need to implement in order to get this to work? Or are we not emitting enough/correct CFI instructions (currently we only emit .cfi_def_cfa in the prolog, we don't have any callee-saved registers).

Speaking of calling conventions: our target is special in that registers are automatically pushed to a special save area upon executing a call, and automatically restored when executing a return instruction. I assume we need to implement some target specific code in stepWithDwarf to handle this?

Any help in this regard would be highly appreciated!

Cheers,

Dominik

[1] https://llvm.org/docs/ExceptionHandling.html
[2] https://www.nongnu.org/libunwind/man/unw_getcontext(3).html

Dominik,

Multiple things are involved:

1. You need to make sure libunwind knows where to look for EH tables.
Usually some communication from dynamic linker or some other way of
obtaining the address of EH table section is necessary
2. You need to describe properly the location of all registers that
need to be restored. If there is something special on your platform,
then you need to implement this functionality in libunwind as well.

You may want to enable debug printing in libunwind – usually it helps a lot.

Hi Anton,

thanks for the reply. I left some comments and questions below.

Dominik,

Multiple things are involved:

1. You need to make sure libunwind knows where to look for EH tables.
Usually some communication from dynamic linker or some other way of
obtaining the address of EH table section is necessary

Since we are on a bare-metal target we only do static linking. We used the following snippet found in AddressSpace.hpp in our linker script:

.eh_frame :
{
__eh_frame_start = .;
KEEP(*(.eh_frame))
__eh_frame_end = .;
}

.eh_frame_hdr :
{
KEEP(*(.eh_frame_hdr))
}

__eh_frame_hdr_start = SIZEOF(.eh_frame_hdr) > 0 ? ADDR(.eh_frame_hdr) : 0;
__eh_frame_hdr_end = SIZEOF(.eh_frame_hdr) > 0 ? . : 0;

And unwind does find the EH tables. It just cannot find an entry which covers the given PC. But I don't know whether the tables or the PC (or both?) are incorrect.

2. You need to describe properly the location of all registers that
need to be restored. If there is something special on your platform,
then you need to implement this functionality in libunwind as well.

Thanks! I assume the correct place to implement this in our case would be stepWithDwarf? I saw some other backends doing some target-specific handling there as well.

You may want to enable debug printing in libunwind – usually it helps a lot.

I already have all traces enabled and also uncommented some fprintf calls, but they just tell me that no entry covers the PC (which was already helpful in that I at least know what is going wrong, just not why).

Cheers,

Dominik