Re: gnat-2017 - ZFP add tasking support

[Robert Eachus <rieachus@comcast.net>]

On Thursday, June 29, 2017 at 5:09:54 AM UTC-4, alby....@gmail.com wrote:
> On Monday, June 26, 2017 at 11:35:38 PM UTC+10, Mark Lorenzen wrote:
> > On Monday, June 26, 2017 at 12:20:49 PM UTC+2, alby....@gmail.com wrote:
> > > On Monday, June 26, 2017 at 5:56:18 PM UTC+10, Mark Lorenzen wrote:
> > > > On Monday, June 26, 2017 at 3:20:22 AM UTC+2, alby....@gmail.com wrote:
> > > > > I was pleasantly surprised that the recent distribution of gnat-2017 (GPL)
> > > > > included a ZFP for native platforms (mine is windows x86). And the project(s)
> > > > > compiled cleanly, even on my personal x64 gnat build
> > > > > 
> > > > > Using this ZFP, along with my WinRT/UWP library, I was a able to build a
> > > > > simple Hello World (XAML based) that now PASSES the "Windows Store app Certification". Note this is a true blue native Windows Store app, and does
> > > > > NOT use the bridging/Centennial technology.
> > > > > 
> > > > > The main caveat in all this is, the use of the ZFP which is fairly
> > > > > restrictive, and does not allow me to use features of Ada that I feel would be
> > > > > a must have running under this environment. In particular "Tasking and maybe
> > > > > controlled types"
> > > > > 
> > > > > Could someone give me guidance on how to add "Tasking" support to the ZFP ?
> > > > > I can use the Mingw-64 code base, I assume its not just as simple as adding
> > > > > these source files to the ZFP source tree ? Is their any other configuration
> > > > > changes needed other than in system.ads ?
> > > > > 
> > > > > Thanks
> > > > > 
> > > > > Alex
> > > > 
> > > > So you want to use the ZERO footprint run-time system, but at the same time you want to use tasks and controlled types? How does this stack up?
> > > > 
> > > > Why don't you simply use the default run-time system?
> > > > 
> > > > Regards,
> > > > 
> > > > Mark L
> > > 
> > > Hi Mark
> > > 
> > > Apologies for the slight confusion, what I should have said/meant was that I
> > > would like to use the ZFP as a base for a new runtime profile (similar to
> > > what AdaCore do for some of their non default run-time systems, such as the
> > > various flavours of Ravenscar and high integrity run-time systems)
> > > 
> > > And yes I could use the default run-time, but in its current form on mingw-64
> > > its NOT certified to be distributed via "Windows Store" since it uses parts
> > > of the "C/C++" runtime that are not compatible with that environment.
> > > 
> > > So I have 2 options
> > > 
> > > 1) Start from the ZFP and add the relevant features such as Tasking
> > > or
> > > 2) Use the default runtime and strip out all the "Windows Store" functions
> > > that are not compatible
> > > 
> > > I would tend to favour the second approach, but the intent of my original
> > > question was to try and determine the amount of effort needed for option 1)
> > > 
> > > Please note that the central theme of incompatibles with the default run-time
> > > and "windows store" are the following
> > > 
> > > a) Store apps have no notion of a "Console" so "C" functions like printf
> > > and family wont work.
> > > b) "C" functions such as memcpy, memset are NOT supported in "Windows Store"
> > > c) There are some other functions in libgnat to do with exception handling
> > > that are also NOT supported in "Windows Store"
> > > 
> > > I hope this helps in clarifying what I am trying to achieve
> > > 
> > > Thanks
> > > 
> > > Alex
> > 
> > OK that makes sense. I would definately try option 2!
> > 
> > Try and look in this document for information on restricted run-time systems: http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug.html You should especially check chapter 5.
> > 
> > Regards,
> > 
> > Mark L
> 
> Hi Mark and Simon
> 
> Thanks for your valued advise, Option 2) was a lot easier to implement than I
> thought it would be. However in removing the "restricted" functions, and I
> believe this centres around the SEH (ie exception handling API's such as
> RtlVirtualUnwind and RtlCaptureContext) I have inadvertently screwed up Ada's
> exception handling !
> 
> I'll try and dig deeper and analyse the issue more deeply, But if anyone could
> give me pointers on the SEH code in "raise_gcc.c", "unwind_seh.c" and
> "traceback.c", that would be greatly appreciated.
> 
> Thanks
> 
> Alex

Normal returns, function returns, and exception unwinding all need to discard stack frames, and set the stack frame pointer and code pointers correctly. (Well the exception unwinding doesn't need to set the code pointer correctly if the stack frame being removed did not have a handler for the exception.  But it is better to treat getting it wrong as a bug.  Bad code pointer values are really nasty.)

What I suggest is some code that prints the two values as the first action in any test procedure or function, print them in a when others handler that then reraises the exception, and finally following the call.  If all three sets are identical, then test the next case. Note that you will need functions which return a scalar, functions which return a record or array on the stack, and functions that raise an exception.  Procedures are easier.  Tasking?  Can be a royal pain.