Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
May 10, 2015 -fno-rtti (disable TypeInfo) support ready for testing | ||||
---|---|---|---|---|
| ||||
I've just opened a pull request for -fno-rtti at [1]. The frontend part needs to go into DMD but I'd like some testing feedback first. This is especially important as I had literally no time to test this updated code ;-) Please provide feedback here or at [1]. -fno-rtti should provide nice, readable error messages: test.d:22:14: error: Can't use typeid: TypeInfo disabled using -fno-rtti switch. auto a = typeid(A); ^ It's however likely that I missed some cases. If you get linker errors or a backend ICE instead of a nice error message please report that. This also prevents the frontend from searching for TypeInfo in object.d which means you can remove those useless fake declarations. A minimal object.d now looks like this: ------------ module object; class Object { } ------------ It can also be empty if you don't need support for classes. If GDC still complains about missing TypeInfo please report that. Note: right now the -fno-rtti switch is not hooked up with -fno-emit-moduleinfo. So you'll probably want all 'fno-invariants -fno-rtti -fno-emit-moduleinfo' options. [1] https://github.com/D-Programming-GDC/GDC/pull/100 |
May 11, 2015 Re: -fno-rtti (disable TypeInfo) support ready for testing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | On Sunday, 10 May 2015 at 17:45:30 UTC, Johannes Pfau wrote: > I've just opened a pull request for -fno-rtti at [1]. The frontend part > needs to go into DMD but I'd like some testing feedback first. This is > especially important as I had literally no time to test this > updated code ;-) Please provide feedback here or at [1]. > Thanks for doing this! I tested my LCD demo and I get the following errors, Compiler command ---------------- arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -mthumb -mcpu=cortex-m4 -fno-bounds-check -fno-invariants -fno-in -fno-out -fno-emit-moduleinfo -fno-rtti -ffunction-sections -fdata-sections {some_imports} {my_source_files} -o binary/firmware.o Compiler output --------------- source/stm32f42/trace.d:58:5: error: Can't use array literal: TypeInfo disabled using -fno-rtti switch. [ ^ cc1d: error: Can't use typeid: TypeInfo disabled using -fno-rtti switch. source/gcc/attribute.d:10:12: error: template instance gcc.attribute.Attribute!string error instantiating return Attribute!A(args); ^ source/gcc/attribute.d:13:45: note: instantiated from here: attribute!(string) public enum inline = gcc.attribute.attribute("forceinline"); Here's the code causing the error --------------------------------- https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/trace.d#L57 private void semihostingWrite(in void* ptr, in uint length) { uint[3] message = [ 2, cast(uint)ptr, length]; // line 58 semihostingInvoke(0x05, &message); } // attribute.d /*************/ private struct Attribute(A...) { A args; } https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/gcc/attribute.d auto attribute(A...)(A args) if(A.length > 0 && is(A[0] == string)) { // line 10 return Attribute!A(args); } //line 13 public enum inline = gcc.attribute.attribute("forceinline"); public enum naked = gcc.attribute.attribute("naked"); Without the -fno-rtti switch, everything builds fine. Mike |
May 11, 2015 Re: -fno-rtti (disable TypeInfo) support ready for testing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | Am Mon, 11 May 2015 12:20:46 +0000 schrieb "Mike" <none@none.com>: > On Sunday, 10 May 2015 at 17:45:30 UTC, Johannes Pfau wrote: > > I've just opened a pull request for -fno-rtti at [1]. The > > frontend part > > needs to go into DMD but I'd like some testing feedback first. > > This is > > especially important as I had literally no time to test this > > updated code ;-) Please provide feedback here or at [1]. > > > > Thanks for doing this! > > I tested my LCD demo and I get the following errors, > > Compiler command > ---------------- > arm-none-eabi-gdc -c -O3 -nophoboslib -nostdinc -nodefaultlibs -nostdlib -mthumb -mcpu=cortex-m4 -fno-bounds-check -fno-invariants -fno-in -fno-out -fno-emit-moduleinfo -fno-rtti -ffunction-sections -fdata-sections {some_imports} {my_source_files} -o binary/firmware.o > > Compiler output > --------------- > source/stm32f42/trace.d:58:5: error: Can't use array literal: > TypeInfo disabled using -fno-rtti switch. > [ > ^ I really need to make that test smarter. Static array init of course doesn't require TypeInfo. As a workaround you could remove this check: https://github.com/D-Programming-GDC/GDC/pull/100/files#diff-5960d486a42197785b9eee4ba95c6b95L4082 > cc1d: error: Can't use typeid: TypeInfo disabled using -fno-rtti > switch. > source/gcc/attribute.d:10:12: error: template instance > gcc.attribute.Attribute!string error instantiating > return Attribute!A(args); > ^ > source/gcc/attribute.d:13:45: note: instantiated from here: > attribute!(string) > public enum inline = gcc.attribute.attribute("forceinline"); > Strange. I'll debug this later this week. > > Here's the code causing the error > --------------------------------- > > https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/trace.d#L57 > private void semihostingWrite(in void* ptr, in uint length) > { > uint[3] message = [ 2, cast(uint)ptr, length]; // line 58 > semihostingInvoke(0x05, &message); > } > > // attribute.d > /*************/ > private struct Attribute(A...) > { > A args; > } > > https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/gcc/attribute.d > auto attribute(A...)(A args) if(A.length > 0 && is(A[0] == > string)) > { > // line 10 > return Attribute!A(args); > } > > //line 13 > public enum inline = gcc.attribute.attribute("forceinline"); > public enum naked = gcc.attribute.attribute("naked"); > > > Without the -fno-rtti switch, everything builds fine. > > Mike |
May 14, 2015 Re: -fno-rtti (disable TypeInfo) support ready for testing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | Am Mon, 11 May 2015 12:20:46 +0000
schrieb "Mike" <none@none.com>:
> source/stm32f42/trace.d:58:5: error: Can't use array literal:
> TypeInfo disabled using -fno-rtti switch.
> [
> ^
> cc1d: error: Can't use typeid: TypeInfo disabled using -fno-rtti
> switch.
> source/gcc/attribute.d:10:12: error: template instance
> gcc.attribute.Attribute!string error instantiating
> return Attribute!A(args);
> ^
The compiler was still building the xopEquals and xopCMP functions. These use TypeInfo internally but they're also only accessible through TypeInfo. Solution: We should not generate these functions with -fno-rtti. Bonus points: You don't need _xopEquals in object.d anymore.
The array error should also be fixed. I've updated the pull
request so you can give it another try.
Thanks for the testing feedback!
|
May 15, 2015 Re: -fno-rtti (disable TypeInfo) support ready for testing | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | On Thursday, 14 May 2015 at 15:21:46 UTC, Johannes Pfau wrote:
^
>
> The compiler was still building the xopEquals and xopCMP functions.
> These use TypeInfo internally but they're also only accessible through
> TypeInfo. Solution: We should not generate these functions with
> -fno-rtti. Bonus points: You don't need _xopEquals in object.d anymore.
>
>
> The array error should also be fixed. I've updated the pull
> request so you can give it another try.
I tested again with the latest changes. Removing the TypeInfo faking reduced my runtime implementation to essentially nothing _d_run_main and a few aliases. My demo builds fine and the resulting binary went from 459k to 6k. The binary also executes as expected, and with such a small binary, I can flash my hardware is less than 500ms.
My test is not very thorough, though, as I intentionally use very little of the language, but this feature is really a great enabler for me, and I think we'll have what we need to make a minimal runtime and toolchain package for C-like bare-metal programming in D.
Thanks for the great work. If there's anything more I can do to move this progress forward, please let me know.
Mike
|
Copyright © 1999-2021 by the D Language Foundation