If none of the HH2_*() macros are used, the binary will show up as its
own filename instead of random garbage.
If HH2_NAME() is used the metadata will be read, and the binary format
requires that all fields by specified. Using only a subset of the macros
is invalid, but not reported.
This reverts commit b0c4e6fd2f.
After investigation, this is related to builtin functions. Using
-fno-builtin is a less invasive way to solve the problem. However this
appears to be a bug [1]; in theory fat LTO objects should solve that. I
will handle this matter at the fxSDK level by adding -fno-builtin right
and experimenting with the bugfix in binutils 2.43.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337
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.