|
From: | Georg-Johann Lay |
Subject: | Re: [avr-gcc-list] avr-gcc: Add --with-avrlibc configure option for AVR-Libc cooperation? |
Date: | Mon, 27 Aug 2012 11:39:31 +0200 |
User-agent: | Thunderbird 2.0.0.24 (Windows/20100228) |
David Brown schrieb:
On 26/08/12 17:33, Georg-Johann Lay wrote:David Brown wrote:Georg-Johann Lay wrote:for historical reasons, AVR-Libc implements functions that GCC expects to live in libgcc, namely float functions like __fixsfsi.Would it not be a better idea to move the functions from AVR-Libc into libgcc? Or are there complicating issues, such as copyright assignments, that make that a harder job? mvh., DavidYes, that's the issue. The original authors put their code in AVR-Libc, presumably because it was easier to get the code in there than to get it into GCC. To get it into GCC, you have to sign a copyright assignment and provide proper patches that passed tests(uite), comply to coding rules, come with ChangeLogs, documentations etc. It's then up to the maintainer to push the code upstream, but he won't fix bugs or typos or coding rules or whatever. For AVR-Libc it's enough to outline a change, at least that was my impression from the improved [u]ltoa functions from SVN 2298. Besides that, even *if* the original authors released their code under an additional license *and* filed FSF copyright assignments, someone would have to actually carry the code migration. From the number of people that contribute to avr-gcc, this is simply not realistic. A potential move has been discussed too often before without any results -- except that it's extremely unlikely anybody will integrate it into libgcc. Adding a new configure option to gcc is much less work and straight forward. All that has to be done is to review the excludes list and make sure that not too much or to less is removed. And run regression tests, of course. The objection against such a change was that it introduces a dependency between avr-gcc and AVR-Libc, but this dependency was introduced long ago, namely when it was decided to re-implement functions that live in libgcc once more in AVR-Libc and use reserved names like __addsf3 together with an "override" hack and implications on how GCC orders -lgcc, -lm, -lc, or how LTO works. In addition to the proposed new t-avrlibc Makefile snippets, there could be defines for, cf. [1] * TARGET_C99_FUNCTIONS * TARGET_HAS_SINCOS Thoughts? Johann [1] http://gcc.gnu.org/onlinedocs/gccint/Library-Calls.htmlOK, since we currently have this situation, then making this new configuration option work is going to be the best way to get full benefits of the externally implemented functions (in avrlibc).But here is a thought - why call the configuration option "--with-avrlibc" ?Surely there are more ports of gcc in exactly the same situation. There are many out-of-tree ports of gcc, and one of the reasons for that is that some of their contributions don't have copyright assignments.And there are many other potential situations where development of code outside of libgcc would be easier, as well as cases when there might be multiple implementations of code (such as "small but slow" or "fast but big" floating point code).
Small vs. fast is a matter of multilib layout. Currently -Os is not a multilib option in avr-gcc, i.e. -Os will not affect the multilib selection. One way to enable -Os is --enable-target-optspace=yes but I don't know if PR2222 is fixed today... Changing multilib layout always raises issues with AVR-Libc because it does not support in-tree builds, see issue #35407.
For all these cases, your patch to make it easier to allow an external library to replace functions from libgcc could be very helpful, if it were made slightly more generic (or at least, had a slightly more generic name).
There are different ways how such a support library could cooperate with GCC. One approach is that the library libfoo uses its own namespace like libfoo_add_float and when the compiler needs a support functions it emits a call to libfoo_add_float instead of as to __addsf3. If I remember correctly, that was the approach taken for the gofast lib. Every library might need it's own special adjustments, and in the case of libgcc functionality it's very likely the support library is not called "libm.a" and does not "override" symbols from libgcc. Moreover AVR-Libc makes assumptions on the ABI, for example it assumes that the compiler always has set -fno-short-double. That may change in the future. It's just some lines to have 64-bit doubles and have -fshort-doubles as new multilib option. This means that SF functions can be thrown out of libgcc, but not the DF functions. The name "--with-avrlibc" is not special, it is just descriptive for what it is intended for. For each "--with-foo=bar" comfigure switch the tools automatically set up a shell variable called "with_foo" and sets it to "bar". In the respective target configuration of config.whatever, just test on that with_foo and hook in makefile snippets or whatever. --with-avrlibc is similar to --with-newlib. The only reason --with-newlib is not needed in general is that newlib supports in-tree builds in GCC: If you hook in a directory called "newlib" to the GCC source tree, it automatically configures and builds and installs newlib together with GCC, including the actual multilib layout. Very nice that. But AVR-Libc does not support in-tree builds, which is a bit uncomfortable if AVR-Libc needs to implement a new multilib layout like the new msp8 multilibs from avr-gcc 4.7. Johann
[Prev in Thread] | Current Thread | [Next in Thread] |