Update compilation flags to exclude...

[Frans-Willem]

malloc and free, signal related functions, and an abort implementation that would pull in file-io related functions.

[projectgus]

Hi Frans-Willem,

Thanks for sending this PR! I realised I hadn't really explained anywhere what this fork is for, either. I just updated the description and added a relevant link to https://github.com/SuperHouse/esp-open-rtos/wiki/libc-configuration

To give some history as well, the original reason I forked from @jcmvbkbc's newlib-xtensa was to add support for linking in FreeRTOS-friendly locking primitives. But then I ended up updating newlib to 2.2.0 in order to bring in the "nano" formatting routines as well.

What are you using it for? It seems like we may have different purposes in mind, but I'd still be happy to work towards a codebase that suits everyone if we can find one.

Regarding the specific additions to the xtensa CFLAGS:

• -DMALLOC_PROVIDED - in esp-open-rtos we rely on newlib for heap management, so we need this for that case.
• -DPREFER_SIZE_OVER_SPEED - the impact of this flag is almost entirely code size rather than RAM footprint. For esp-open-rtos we link almost all of libc to irom, so a few extra few kilobytes is not really a noticeable overhead. We're also working towards storing all of .rodata in irom rather than DRAM, and the "speed" versions the string functions do word-sized reads where possible rather than byte-sized reads, which makes for a huge performance boost in this case.
• -DSIGNAL_PROVIDED - This is a good catch. There's no real overhead to not specifying it, you just get a link-time error when the syscalls for _signal_r/_getpid_r aren't found. Better to have it and see the error at compile time though, I guess.
• -DABORT_PROVIDED - Same as with signal, I agree this is a good catch to let people write their own abort(). Thanks!

In terms of finding a single codebase solution, I think part of the problem is that xtensa is a whole CPU architecture (not just esp8266), and xtensa-lx106-elf is just a CPU. Maybe we need a way to provide OS-specific targets to the libc at configure time? Or maybe these really are just configure arguments to supply via a CFLAGS argument to configure, rather than things to code into the configure layer?

[Frans-Willem]

Hey,

I'm using it as a generic newlib for esp8266 development. Seeing as the SDK already provides os_malloc, I figured malloc shouldn't be provided by newlib, especially since there's no sbrk implementation anyway.
The main reason I got to the pull request was because std::string was pulling in write_r/read_r/sbrk_r/getpid_r and all sorts of other things just because there was an abort call somewhere in there.
I've since solved most of the problems by providing an abort function instead, but still felt like in such cases it's better to have linker errors about stubs that should be provided (e.g. abort), instead of all the stuff newlib tries to pull in for it's (overly generic) default implementation.

I wonder if it'd be possible to change some of these things from ./configure. I'd rather have one main newlib repository for ESP8266/xtensa-lx106 development (possibly even mainlined?) than have different versions for different purposes :/

[projectgus]

Sorry for the slow reply.

I'm a bit stuck on how exactly to do this.

Passing CFLAGS= or TARGET_CLAGS= options to ./configure seem to be ignored no matter how I set them.

On the other hand configure.host seems to rely pretty heavily on the "one compiler tuplet equals one set of host flags" rule, so I can't find an easy way to have multiple options there either.

Do you have any ideas? I can ask the newlib mailing list but I'd like to make really sure I'm not missing something obvious first.

[projectgus]

Figured out something that works.

Configure as normal, and then do something like:

CROSS_CFLAGS="-DHAVE_MALLOC -DPREFER_SIZE_OVER_SPEED -DSIGNAL_PROVIDED -DABORT_PROVIDED" make

[Frans-Willem]

Ah, that's a good one too :)
I had personally already used 'sed' to manipulate the configure.host before compilation (see https://github.com/Frans-Willem/arch-esp8266-packages/blob/master/xtensa-lx106-elf-newlib-projectgus/PKGBUILD)

Either way, I agree with you about the fact that not all purposes require similar compilation flags, and I suppose both solutions are valid :)