<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 18, 2021, 5:13 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17/4/21 10:00 am, Kinsey Moore wrote:<br>
> On 4/16/2021 08:48, Gedare Bloom wrote:<br>
>> On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber<br>
>> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>>> Hello Kinsey,<br>
>>><br>
>>> why don't you use a fatal error extension for this? You can save all the<br>
>>> processor state to a structure and use it to jump to previous or next<br>
>>> instruction it if needed in a custom fatal error handler which deals<br>
>>> with RTEMS_FATAL_EXCEPTION. I think libdebugger uses this approach.<br>
>>><br>
>> +1<br>
>><br>
>> This is otherwise a major overhaul/addition to the CPU port<br>
>> requirements. I'd lean in favor of adding any CPU_* API that is<br>
>> necessary to support vectoring from an exception to a signal. I don't<br>
>> think we can make this kind of intrusive modification to basic<br>
>> interrupt handling capabilities across all ports easily. Some of that<br>
>> code is old and very stable.<br>
> <br>
> I avoided going that direction to maintain the interrupt stack since an<br>
> exception return from within those handlers would necessarily leave the CPU<br>
> state as well as intervening functions on the stack along with a minor amount of<br>
> data on the thread stack. In addition, thread dispatch needs to occur and all<br>
> exception handling for AArch64 (as modeled after ARM) is currently considered<br>
> final with no way to reasonably return to execution.<br>
> <br>
> Not every platform will need this kind of intrusive change. Any platform that<br>
> handles exceptions in a manner similar to IRQs can deal with this exception<br>
> mapping far more trivially. ARM and AArch64 don't have that luxury, but SPARC<br>
> does and I assume others do as well.<br>
<br>
How would a user in an application debug a data abort error if all they get is a<br>
signal?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is optional and just the way certain Ada exceptions work. If the user wanted more detail, they would like have to poke directly before it becomes a signal.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How would this type of signal support be implemented on the 32bit ARM arch and<br>
maintain libdebugger support?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Is there a technical limitation I don't know about? On the SPARC, it recognizes that only certain faults can be mapped.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
How would libdebugger be integrated on the aarch64 with this change?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Again what's the limitation? You appear to there's something about the architecture that would cause a clash.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>