Summary: | gnatbind generates invalid code when finalization is enabled in restricted runtime | ||
---|---|---|---|
Product: | gcc | Reporter: | simon |
Component: | ada | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | charlet, ebotcazou, ramana |
Priority: | P3 | ||
Version: | 4.9.1 | ||
Target Milestone: | 8.0 | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | 4.9.1, 5.1.0, 6.1.0, 7.1.0, 8.0 | Last reconfirmed: | 2015-06-11 00:00:00 |
Bug Depends on: | 66242 | ||
Bug Blocks: | |||
Attachments: |
Patch to gcc/ada/bindgen.adb
Patch to gcc/ada/bindgen.adb |
Eric, Would you be able to comment further ? Ramana As a side note, AdaCore’s document on “The GNAT Configurable Run Time Facility”, section 5.5.2[1], says about Suppress_Standard_Library "All finalization and initialization (controlled types) is omitted”. I don’t think this is right; the only part of the standard s-stalib related to finalization is the procedure Adafinal, which is I think irrelevant to a runtime that doesn’t support program termination. [1] http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/the_gnat_configurable_run_time_facility.html#specification-of-configuration-parameters This combination is probably not supported. Nothing to do with ARM in any case. Agree it’s not ARM-specific, but it _is_ Ada-restricted-runtime-specific. I realise that this isn’t a configuration supported by AdaCore for their customers (there’d have been no need for this PR if it was!); does it have to be unsupported by GCC then? I’ve managed to make what I think is a very-low-quality workround by (a) not suppressing the standard library on the target in system.ads (b) including a C source file in the RTS which provides dummies for the irrelevant-in-this-context __gl_* objects which bindgen now references. Anyway, now I have my copyright assignment in place, I’ll submit the patch. I’m not sure what regression tests would be appropriate: I propose to apply the patch and bootstrap/make check-ada for Darwin, that will show I haven’t broken the normal case, and I can repeat the build for arm-eabi and build a null main program. If there’s no chance that this patch will ever be accepted, please let me know before I embark on this! > I???ve managed to make what I think is a very-low-quality workround by
> (a) not suppressing the standard library on the target in system.ads
> (b) including a C source file in the RTS which provides dummies for the
> irrelevant-in-this-context __gl_* objects which bindgen now
> references.
>
> Anyway, now I have my copyright assignment in place, I???ll submit the
> patch. I???m
> not sure what regression tests would be appropriate: I propose to apply the
> patch and bootstrap/make check-ada for Darwin, that will show I haven???t
> broken
> the normal case, and I can repeat the build for arm-eabi and build a null main
> program.
>
> If there???s no chance that this patch will ever be accepted, please let me
> know before I embark on this!
Certainly a very low quality workaround won't be accepted, this would cause
too much maintenance troubles.
Arno
(In reply to charlet@adacore.com from comment #5) > Certainly a very low quality workaround won't be accepted, this would cause > too much maintenance troubles. Sorry for the confusion. The patch I propose is the one attached to this PR; the VLQ workround is what I will have to do, not as part of GCC of course, if the patch is rejected. Note the workround would appear only in a restricted runtime, which would be like AdaCore’s restricted runtimes in that it wouldn’t be part of the official GCC tree, even though the copyright would be assigned to FSF. Created attachment 36690 [details]
Patch to gcc/ada/bindgen.adb
Still fails in version 7.0.1 20170302 (experimental) (GCC). Still fails in 8.0.0 20171102. I’m quite happy to work out an updated patch (there doesn’t appear to be much change required), but only if there is at least _some_ chance it might get included. Author: ebotcazou Date: Wed Dec 6 09:42:57 2017 New Revision: 255441 URL: https://gcc.gnu.org/viewcvs?rev=255441&root=gcc&view=rev Log: PR ada/66205 * bindgen.adb (Gen_AdaFinal): If the restriction No_Task_Termination is set, generate a null body. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/bindgen.adb Thanks for the patch. Author: charlet Date: Tue Dec 19 08:43:49 2017 New Revision: 255811 URL: https://gcc.gnu.org/viewcvs?rev=255811&root=gcc&view=rev Log: PR ada/66205 * bindgen.adb (Gen_AdaFinal): Revert previous change. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/bindgen.adb As discussed on gcc-patches@, this isn't the right approach after all. Instead, you should set Suppress_Standard_Library_On_Target to False in your target system.ads, this is the only combination that is supported by the binder and the runtime to enable finalization in a restructed runtime. Arno . I think this was actually INVALID. I’m glad to report that Arno’s notes in Comment #14 do in fact solve the problem (after supplying dummies for the parts of the standard library that aren’t actually present -- __gl_wc_encoding etc). |
Created attachment 35567 [details] Patch to gcc/ada/bindgen.adb This is on 4.9.1 compiled for arm-eabi on Mac OS X Mavericks (Darwin 13). Please note that the same problem occurs with 5.1.0. package System has pragma Profile (Ravenscar); pragma Restrictions (No_Enumeration_Maps); pragma Restrictions (No_Exception_Propagation); pragma Restrictions (No_Recursion); and the result of a gprbuild is gprbuild -p -P testbed gprbind testbed.bexch arm-eabi-gnatbind testbed.ali arm-eabi-gcc -c b__testbed.adb b__testbed.adb:31:14: "Is_Elaborated" is undefined (more references follow) gprbind: compilation of binder generated file failed gprbuild: unable to bind testbed.adb which happens because bindgen.adb has at :2497 if not Suppress_Standard_Library_On_Target then WBI (" Is_Elaborated : Boolean := False;"); end if; but at :408 in the generation of adafinal if not CodePeer_Mode then WBI (" if not Is_Elaborated then"); WBI (" return;"); WBI (" end if;"); WBI (" Is_Elaborated := False;"); end if; I’ve worked out a patch for this, but I’m confused about when to use Suppress_Standard_Library_On_Target vs Configurable_Run_Time_On_Target vs Configurable_Run_Time_Mode to determine that adafinal will never actually be called & hence needn’t do anything. Not sure whether __gnat_initialize, __gnat_finalize are expected (they aren’t in the AdaCore arm-eabi libraries), so I’ve suppressed them too.