proof of concept: error if float->u64 cast used

[jepler]

When the change to fix use of this routine via the case '(uint64_t)(float expression)' is reverted, this error occurs during the build of feather_m4_express:

.../firmware.elf.lto.o: in function `usb_cdc_serial_write_stream':
.../Serial.c:81: undefined reference to `__aeabi_f2ulz'
.../ld: firmware.elf.lto.o: in function `usb_cdc_serial_read_stream':
.../Serial.c:44: undefined reference to `__aeabi_f2ulz'

I don't exactly know why it says that __aeabi_f2ulz is the undefined symbol, since it's actually some other symbol (__bad_use_of_float_to_u64_cast) which is undefined, but I'll take it.

I don't know if we actually want this, but as I think the problem has arisen more than once it may not hurt. Let's see what CI says.

[dhalbert]

This is an interesting approach. I was thinking of grepping the firmware.elf.map for the unwanted symbols.

[tannewt]

This looks fine to me! Maybe the error is post-inlining?

[tannewt]

@dhalbert Are you ok merging?

[dhalbert]

I'm OK merging, but there are other cases where we bring in various routines, and __aeabi_f2ulz may not always be something brought in. For instance, __aeabi__dadd might get called by accident if double-precision is accidentally invoked. So perhaps just examining the firmware.elf.map for various "uh-oh" symbols could be more comprehensive.

[jepler]

we can use this "mold" to add other symbols too, as far as I know. but otoh this is only covering one port, and looking at firmware.elf.map would at least cover all arm-based ports... I'm fine if we want to not do this right now either -- close if you prefer

[dhalbert]

I think I would rather just scan the .map file, because then we can print out a useful error message instead having to rely on a link error. So I will close. But I do very much like the idea of catching inadvertent addition of chunky helper routines.