As of now (fxSDK 2.11), this flag is set globally by the fxSDK, so this
change doesn't have an immediate effect. However, I've been
experimenting with removing -ffreestanding at the global level to allow
applications to build with the hosted C++ library (which isn't fully
supported by has many supported features, like containers, that aren't
available in free-standing mode).
Without -ffreestanding, LTO makes weird decisions and ends up pruning
way too many symbols from libraries, leading to undefined references for
symbols provided by the standard library. Here is a minimal example.
---
% cat abort.c
void abort(void)
{
__builtin_unreachable();
}
% cat main.c
extern void abort(void);
int start(void)
{
abort();
return 0;
}
% cat sh-min.x
ENTRY(_start)
OUTPUT_FORMAT(elf32-sh)
SECTIONS {
. = 0x1000;
.text : { *(.text) }
.data : { *(.data) }
.bss : { *(.bss) }
}
% sh-elf-gcc -flto -nostdlib -ffreestanding -c abort.c -o abort.o
% sh-elf-gcc-ar rcs abort.a abort.o
% sh-elf-gcc -flto -nostdlib -c main.c -o main.o
% sh-elf-gcc -flto -nostdlib -save-temps main.o -o main -T ./sh-min.x abort.a -lgcc
ld: ./main.ltrans0.ltrans.o: in function `_start':
<artificial>:(.text+0xc): undefined reference to `_abort'
---
To solve the bug in this example, add -ffreestanding when making main.o.
I haven't been able to sufficiently dump/introspect intermediate files
to understand what's happening yet. It's also unclear whether the fix is
clean since LTO normally requires all files to be built with the same
settings, so adding -ffreestanding to gint but not the add-in seems
suspicious. There is, however, an inherent incompatibility in the
conjunction of (1) building kernels with -ffreestanding, (2) building
add-ins that use the C++ library thus require -fhosted, and (3) only
linking objects files built with the same options.
* Set -flto
* Use gcc-ar to build the archive so the LTO plugin is loaded and LTO
sections aren't stripped off the object files
* Slightly conservative KEEP()s in the linker script (not required but
I'm paranoid)
* Make the drivers __attribute__((externall_visible)) so they are
generated by the link-time back-end and not left in the archive
* Remove the unused isappli/optnum parameters of main, which have been
unused for years, are irrelevant on fx-CG and lead to a link-time
warning with LTO. I'll add APIs to access them later.
Features will come in slowly while I restructure for gint 3. With this
third big target for gint, the legacy aspects of gint 2's structure and
API are getting felt, so a major revision will be in order.
See the TODO file at this commit for info on what works and not.
- Define a draft of the video interface
- Implement that dragt for CG for a single mode
* Includes stub of brightness setting from disassembling 3.60
- Use the video interface to show visual feedback on GDB on CG
Using the video interface avoids directly linking into a driver, which
will serve modularity in gint 3.
It's not super useful as a feature but it means that a naive "continue"
after e.g. a segfault will kill the program and not confusingly go into
an infinite loop.
The user can still gdb_start() + gdb_main(NULL) manually, which allows
e.g. early setup of breakpoints. The start_on_except mechanism is the
lazier method where we just run the add-in normally and start fxsdk gdb
on the PC *after* a crash occurs.
It is guaranteed by the driver model that drivers are powered on when
gint is active. Sharing the driver isn't too useful because we can't
remote debug in the OS world anyway, there's no USB driver there.
Not changing much for now, just distilling them into hardware/OS/render
macros. Later on the rendering stuff will become more dynamic and down
the line I want to unify the APIs more.
Nothing interesting in this commit, just moving files around, making
sure every target compiles every file, and controlling with macros
instead.
Basic support for fxg3a target in CMakeLists.txt, cmake/FindGint.cmake,
giteapc.make and include/gint/config.h.in. The rest is forgettable.
This is the first of many steps designed to reduce gint's reliance on
the FX9860G and FXCG50 macros by describing the compile target more
symbolically. The goal is to allow both for g3a compilation of fx-API
code and for a potential CP port.
* Honor dwindow settings immediately (avoids useless dline() calls)
* Bound to ymin/ymax instead of doing many useless cut computations
* Remove the need for floating-point operations and division
