Dominik Montada via llvm-dev
2020-Jul-03 10:22 UTC
[llvm-dev] 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 Montada Email: dominik.montada at hightec-rt.com HighTec EDV-Systeme GmbH Phone: +49 681 92613 19 Europaallee 19 Fax: +49-681-92613-26 D-66113 Saarbrücken WWW: http://www.hightec-rt.com Managing Director: Vera Strothmann Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6822 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200703/b05bfe3e/attachment.bin>
Anton Korobeynikov via llvm-dev
2020-Jul-03 15:48 UTC
[llvm-dev] Exceptions not getting caught on bare-metal target
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. On Fri, Jul 3, 2020 at 1:22 PM Dominik Montada via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > 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 Montada Email: dominik.montada at hightec-rt.com > HighTec EDV-Systeme GmbH Phone: +49 681 92613 19 > Europaallee 19 Fax: +49-681-92613-26 > D-66113 Saarbrücken WWW: http://www.hightec-rt.com > > Managing Director: Vera Strothmann > Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222 > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient please notify the sender immediately > and destroy this e-mail. Any unauthorised copying, disclosure or > distribution of the material in this e-mail is strictly forbidden. > --- > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University
Dominik Montada via llvm-dev
2020-Jul-06 07:05 UTC
[llvm-dev] Exceptions not getting caught on bare-metal target
Hi Anton, thanks for the reply. I left some comments and questions below. Am 03.07.20 um 17:48 schrieb Anton Korobeynikov:> 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 necessarySince 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> > On Fri, Jul 3, 2020 at 1:22 PM Dominik Montada via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> 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 Montada Email: dominik.montada at hightec-rt.com >> HighTec EDV-Systeme GmbH Phone: +49 681 92613 19 >> Europaallee 19 Fax: +49-681-92613-26 >> D-66113 Saarbrücken WWW: http://www.hightec-rt.com >> >> Managing Director: Vera Strothmann >> Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222 >> >> This e-mail may contain confidential and/or privileged information. If >> you are not the intended recipient please notify the sender immediately >> and destroy this e-mail. Any unauthorised copying, disclosure or >> distribution of the material in this e-mail is strictly forbidden. >> --- >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- ---------------------------------------------------------------------- Dominik Montada Email: dominik.montada at hightec-rt.com HighTec EDV-Systeme GmbH Phone: +49 681 92613 19 Europaallee 19 Fax: +49-681-92613-26 D-66113 Saarbrücken WWW: http://www.hightec-rt.com Managing Director: Vera Strothmann Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6822 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200706/0d5541d2/attachment.bin>