Extended Exceptions and other tweaks.

[Diogenes]

First of all...thanks to everyone who have given me pointers on my initial runtime hacking experiments. I'm really trucking now.

Currently, just to gain some experience in this area, I building my own runtime targeted to the Native platform, but using a much more rigorous process. Using the Spark tools, unit testing everything, etc...

Since I'm working on the Ada Exceptions mechanism, I began to wonder if it might not make sense to add security related exceptions as a possible extension. I have ACLs going on one machine here, and of course Caps going on others.

Would something like this be useful to the community, or would it be too much? Since a security related exception does not necessarily indicate an error in the program itself; it could indicate a conflict with the policy set up by a System Administrator. Seems like it might be prudent to indicate that explicitly.

Are there any other tweaks or extensions that people might find useful?

Diogenes

[Shark8]

I don't know if it would be useful/helpful; it certainly sounds interesting to me though.

[Brian Drummond]

On Sat, 30 Mar 2013 13:01:51 -0700, Diogenes wrote:

> First of all...thanks to everyone who have given me pointers on my
> initial runtime hacking experiments. I'm really trucking now.
>
> Currently, just to gain some experience in this area, I building my own
> runtime targeted to the Native platform, but using a much more rigorous
> process. Using the Spark tools, unit testing everything, etc...
>
> Since I'm working on the Ada Exceptions mechanism, I began to wonder if
> it might not make sense to add security related exceptions as a possible
> extension. I have ACLs going on one machine here, and of course Caps
> going on others.

I can't comment on extended exceptions.

However, when supporting exceptions in his RTS, Luke apparently ran into
difficulties. If you have had more success - either using a different
approach, or following his but overcoming his difficulties, then that
would be useful. Is this going to be documented and/or made available
somewhere?

- Brian

[Diogenes]

On Saturday, March 30, 2013 6:10:07 PM UTC-4, Brian Drummond wrote:
>
> I can't comment on extended exceptions.
>
>
>
> However, when supporting exceptions in his RTS, Luke apparently ran into
>
> difficulties. If you have had more success - either using a different
>
> approach, or following his but overcoming his difficulties, then that
>
> would be useful. Is this going to be documented and/or made available
>
> somewhere?
>
>
>
> - Brian

Assuming it IS in fact successful, I will post it up here.

Exceptions are definitely one of the more difficult mods to the Runtime. I'll document it IF it actually works properly.

[Stephen Leake]

Diogenes <phat...@gmail.com> writes:

> First of all...thanks to everyone who have given me pointers on my
> initial runtime hacking experiments. I'm really trucking now.
>
> Currently, just to gain some experience in this area, I building my
> own runtime targeted to the Native platform, but using a much more
> rigorous process. Using the Spark tools, unit testing everything,
> etc...
>
> Since I'm working on the Ada Exceptions mechanism, I began to wonder
> if it might not make sense to add security related exceptions as a
> possible extension. I have ACLs going on one machine here, and of
> course Caps going on others.

I suggest that could be handled in current Ada; just add an appropriate
messsage to Use_Error.

--
-- Stephe

[Luke A. Guest]

The problem I had was defining my own exceptions and raising them, i.e. I
could define but not raise, even though the bare machine runtime is
supposed to allow it, it doesn't and you need more mechanisms todo it.

Luke

[Brian Drummond]

On Sat, 30 Mar 2013 18:18:24 -0700, Diogenes wrote:

> On Saturday, March 30, 2013 6:10:07 PM UTC-4, Brian Drummond wrote:
>>
>> Is this going to be documented and/or made available

> Assuming it IS in fact successful, I will post it up here.
>
> Exceptions are definitely one of the more difficult mods to the Runtime.
> I'll document it IF it actually works properly.

Even knowing the point of failure (if unsuccessful) could be useful.

To Luke : thanks for the clarification on your experiments.

- Brian

[Lucretia]

On Monday, 1 April 2013 21:36:58 UTC+1, Brian Drummond wrote:

> To Luke : thanks for the clarification on your experiments.

No problems. There is confusion here because the documentation alludes to it being doable, AdaCore even say it can be done on their site and in their manuals. When I asked about it, the reply from AdaCore was that it can't, weird.

In fact the bug report is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53684 and as usual, monosyllablic style responses :/

So, it could be that it's a difference between FSF and GPL or FSF and Pro, I don't know.

Luke.

[rrr.e...@gmail.com]

The comment #2 in the mentioned bug report is correct. Also in the configurable run time mode you need the files a-except.ad[sb]. They can be very short, however. Have look at these files in the latest AVR-Ada (V1.2.1). Local exceptions -- including user defined ones -- are possible in AVR-Ada.

Rolf

[Brian Drummond]

On Sun, 07 Apr 2013 13:20:52 -0700, rrr.eee.27 wrote:

> On Saturday, April 6, 2013 5:49:55 PM UTC+2, Lucretia wrote:
>> On Monday, 1 April 2013 21:36:58 UTC+1, Brian Drummond wrote:

>> > To Luke : thanks for the clarification on your experiments.

>> In fact the bug report is
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53684 and as usual,
>> monosyllablic style responses :/
>>
>

> The comment #2 in the mentioned bug report is correct.

I can't see a comment #2 in that report?

> Also in the
> configurable run time mode you need the files a-except.ad[sb]. They can
> be very short, however. Have look at these files in the latest AVR-Ada
> (V1.2.1). Local exceptions -- including user defined ones -- are
> possible in AVR-Ada.

It would be interesting to know if porting these helps Luke's situation.

I have borrowed the AVR-Ada RTS as a starting point for the TI MSP430 and
it's looking good so far. I haven't tried exceptions yet though, but I'll
report when I get that far.

- Brian

[Brian Drummond]

Played with exceptions tonight; they look better than I expected and I
think I can shed some light on Luke's experiments.

(NOTE: all the following apply with "pragma No_Exception_Propagation" in
effect)

The a-except.ad[sb] from AVR-Ada _nearly_ worked for the MSP430 as well!
The address clause on "procedure Reset" was the only point of failure so
far, as it is not 0 on the MSP430 but 16#FF80# or other CPU-dependent
value.

What's untested so far:
Actually running the executables : so far I have just examined the code
emitted by the compiler

Raising exceptions as a result of runtime errors (overflow etc) instead
of explicit Raise statements.

What works :
Raising a standard exception.
Handling it locally
Handling it in the Last Chance Saloon (cough, Handler).

Raising a user-defined exception, declared immediately visible to the
subprogram which raises and handles it.
Handling it locally.
Handling it in the Last Chance handler.

Raising a user-defined exception, declared elsewhere - even in a local
package.
Handling it in the Last Chance handler.


What doesn't work :

Locally handling a user-defined exception from another package, via a
selected name. The compiler ignores (deletes) any local handler and
passes the exception (actually just plants a call to) the Last Chance
handler. However, making the exception directly visible via a Use clause,
it does work.

So the following ,

raise Timer_A.oops; -- last chance handler!
and
use Timer_A;
raise oops; -- can be locally handled

end up in different exception handlers!

I'm not clear on whether this is expected behaviour...

- Brian

[Randy Brukardt]

"Brian Drummond" <br...@shapes.demon.co.uk> wrote in message
news:kls8v6$70i$1...@dont-email.me...
...

> So the following ,
>
> raise Timer_A.oops; -- last chance handler!
> and
> use Timer_A;
> raise oops; -- can be locally handled
>
> end up in different exception handlers!
>
> I'm not clear on whether this is expected behaviour...

It's certainly not Ada behavior. But since you didn't show the local
handler, there's a possibility that the problem was there, rather than in
the exception raise. More likely, it is just some sort of compiler bug.

Randy.

[Yannick Duchêne (Hibou57)]

Le Sun, 31 Mar 2013 03:18:24 +0200, Diogenes <phat...@gmail.com> a écrit:
> Exceptions are definitely one of the more difficult mods to the Runtime.
> I'll document it IF it actually works properly.

And added to that, many part of the runtime have dependencies on the
exceptions support.

--
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

[Brian Drummond]

On Wed, 01 May 2013 20:06:20 -0500, Randy Brukardt wrote:

> "Brian Drummond" <br...@shapes.demon.co.uk> wrote in message
> news:kls8v6$70i$1...@dont-email.me...
> ...
>> So the following ,
>>
>> raise Timer_A.oops; -- last chance handler!
>> and use Timer_A;
>> raise oops; -- can be locally handled
>>
>> end up in different exception handlers!
>>
>> I'm not clear on whether this is expected behaviour...
>
> It's certainly not Ada behavior.

I have failed to reproduce that one with the native compiler...
However I did find this interesting specimen: (source below)

The compiler apparently agrees with my understanding of
"pragma Restrictions (No_Exception_Propagation)" which is:
Immediately local exception handler is allowed;
Last chance handler is allowed; (and raising another exception in "doit2"
will indeed reach the Last chance handler)
Anything in between is (a) not permitted and (b) will not run...

gnatmake -gnatwa -gnatw.x test_eh.adb
gcc -c -gnatwa -gnatw.x test_eh.adb
test_eh.adb:16:07: warning: pragma Restrictions
(No_Exception_Propagation) in effect
test_eh.adb:16:07: warning: execution may raise unhandled exception
test_eh.adb:27:04: warning: pragma Restrictions
(No_Exception_Propagation) in effect
test_eh.adb:27:04: warning: this handler can never be entered, and has
been removed

but the resulting executable does not...

./test_eh
Main program start
Local handler : oops!
Second try
No_Exception_Propagation: this cannot happen...

Now is there a reasonable explanation that I have missed, or is this
worth reporting as a compiler bug?

- Brian



Compiler versions:
FSF Gnat 4.6.3, 4.7.2
GNATMAKE GPL 2011 (20110419)

Source :
--------------------------------------------------------------------
pragma Restrictions (No_Exception_Propagation);

with Ada.Text_IO; use Ada.Text_IO;

procedure Test_EH is

Oops : exception;

procedure doit is begin
raise Oops;
exception
when Oops => Ada.Text_IO.Put_Line("Local handler : oops!");
end doit;

procedure doit2 is begin
raise Oops; -- line 16
-- raise Program_Error;
end doit2;

begin
Ada.Text_IO.Put_Line("Main program start");
doit;
Ada.Text_IO.Put_Line("Second try");
doit2;
Ada.Text_IO.Put_Line("Main program done");
exception
when Oops => Ada.Text_IO.Put_Line -- line 27
("No_Exception_Propagation: this cannot happen...");
end Test_EH;
--------------------------------------------------------------------

[Randy Brukardt]

"Brian Drummond" <br...@shapes.demon.co.uk> wrote in message

news:km5k24$3v9$1...@dont-email.me...
...

> The compiler apparently agrees with my understanding of
> "pragma Restrictions (No_Exception_Propagation)" which is:

This is not an Ada-language defined pragma, so...

> Now is there a reasonable explanation that I have missed, or is this
> worth reporting as a compiler bug?

...it can do anything the implementer desires. Meaning that formally at
least, there is no grounds for a bug no matter what does. Whether it is
doing what was intended is another question altogether.

Randy.