On 4/18/2021 20:18, Chris Johns wrote:
On 19/4/21 9:23 am, Joel Sherrill wrote:
On Sun, Apr 18, 2021, 5:13 PM Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>> wrote:
On 17/4/21 10:00 am, Kinsey Moore wrote:
> On 4/16/2021 08:48, Gedare Bloom wrote:
>> On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
>> <sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>> Hello Kinsey,
>>>
>>> why don't you use a fatal error extension for this? You can save all
the
>>> processor state to a structure and use it to jump to previous or next
>>> instruction it if needed in a custom fatal error handler which deals
>>> with RTEMS_FATAL_EXCEPTION. I think libdebugger uses this approach.
>>>
>> +1
>>
>> This is otherwise a major overhaul/addition to the CPU port
>> requirements. I'd lean in favor of adding any CPU_* API that is
>> necessary to support vectoring from an exception to a signal. I don't
>> think we can make this kind of intrusive modification to basic
>> interrupt handling capabilities across all ports easily. Some of that
>> code is old and very stable.
>
> I avoided going that direction to maintain the interrupt stack since an
> exception return from within those handlers would necessarily leave the
CPU
> state as well as intervening functions on the stack along with a minor
amount of
> data on the thread stack. In addition, thread dispatch needs to occur
and all
> exception handling for AArch64 (as modeled after ARM) is currently
considered
> final with no way to reasonably return to execution.
>
> Not every platform will need this kind of intrusive change. Any platform
that
> handles exceptions in a manner similar to IRQs can deal with this
exception
> mapping far more trivially. ARM and AArch64 don't have that luxury, but
SPARC
> does and I assume others do as well.
How would a user in an application debug a data abort error if all they
get is a
signal?
This is optional and just the way certain Ada exceptions work.
Optional means what? What about other optional pieces?
Does the change have a wider use case than Ada? I think it may which is good.
As a result I feel we need to consider other users of exceptions and how they
may interact with this change.
I think Joel meant optional the same way libdebugger is optional. This
change operates the same way on AArch64 that libdebugger operates on ARMv7.
If the user
wanted more detail, they would like have to poke directly before it becomes a
signal.
I would connect a debugger and then expect to have the pc left at the faulting
instruction. At a technical level this means the faulting exception frame needs
to be handled and not compacted down to a single signal. On a 32 bit ARM it is a
very difficult piece of code and I would be pleasantly surprised if you did not
need this on an aarch64.
It's likely to be just as painful as ARMv7. I spent part of the morning
reviewing the relevant libdebugger code and both hook directly into the
vector table. As things stand, libdebugger and this code can not coexist
on ARMv7 or AArch64.
How would this type of signal support be implemented on the 32bit ARM arch
and
maintain libdebugger support?
Is there a technical limitation I don't know about? On the SPARC, it recognizes
that only certain faults can be mapped.
Not specifically, I am just wondering how each part of our code integrates. Does
adding aarch64 to libdebugger need to work with these changes so the signal
exception confdef option is still works? And then the other way around does
adding exception signal support to the 32 bit ARM have to deal with libdebugger
as it exists? Who is paying the tax and what does it look like?
The current implementation of both libdebugger on ARMv7 and this
exception to signal translator on AArch64 are very similar in how they
operate. libdebugger on ARMv7 hooks every exception type at the vector
table while this translator hooks the common/unified exception vector
for AArch64. There isn't currently a way they could even partially share
the exceptions as there isn't a mechanism available to register hooks to
them individually.
Some form of sharing could be possible on SPARC since both exceptions
and IRQs are just different ranges of traps (all of which have handler
hooks), but with possibly reduced functionality on the libdebugger side
since some of the exceptions libdebugger typically catches would instead
get translated and pushed into whichever runtime was operating, be it
Ada, C++, Fortran, etc..
How would libdebugger be integrated on the aarch64 with this change?
Again what's the limitation? You appear to there's something about the
architecture that would cause a clash.
Are the exceptions a shared resource or exclusive? If shared, how? If exclusive
does this mean an aarch64 libdebugger back end does not need to deal with the
same exceptions and this change?
They are currently exclusive as a block as implemented on ARMv7 and
AArch64. For these two to coexist, there would need to be a mechanism to
attach handlers to various machine-specific exceptions. They could also
be shoehorned into the interrupt handler table at an offset to get
behavior more similar to SPARC.
Are the exceptions chained?
Neither libdebugger nor signal translation allows for exception chaining.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
