Fwd: GCC 4.7.0 Release Candidate available from gcc.gnu.org
ralf.corsepius at rtems.org
Wed Mar 7 15:21:05 UTC 2012
On 03/07/2012 08:45 AM, Thomas Doerfler wrote:
> Am 06.03.2012 09:39, schrieb Ralf Corsepius:
>> Anyway, that said, I would not be surprized if some parts of RTEMS
>> (esp. BSPs) still carry implict dependencies on non-eabi and have never
>> ever seen any real world testing with EABI.
> If these hidden problems have not been detected in the last months,
> going on with two parallel toolchain flavours will neither reveal nor
> fix them. So forcing a flavour change may seem a harsh step but will
> force all ARM users to use EABI and therefore detect/report problems.
Well, in RTEMS history there have been several situations, where staying
with officially discontinued ABIs/features was the only option for some
* users could be using third party closed source libraries, which would
be ABI incompatible to the "new ABI" and therefore prevent them from
switching to a different ABI.
* an ABI change may introduce others side-effects which may render using
a new ABI impossible in some cases. E.g. the coff->elf change many years
ago had introduced increases in application sizes which rendered using
elf-RTEMS impossible on certain boards and had forced people to stay
>> In other words, in case we can not avoid to abandon non-EABI arm, we
>> need to identify these eabi un-tested parts in RTEMS and to remove them
>> from rtems-4.11. My guess would be this is half of the arm BSPs.
> I don't get your conclusion to "remove" _untested_ parts. If they are
> _unused_, they should be removed. If they are in use and are broken with
> EABI, they should be fixed.
My intention is to utilize this ABI change as an opportunity to separate
dead code from code really being in use (esp. dead BSPs).
> It's the difference of preserving code (and keeping it alive as along as
> possible without touching it) or adapting it to evolving standards.
Well, that's a general problem with RTEMS. At some point, keeping dead
code starts to backfire and only serves the purpose of keeping people
busy with keeping code compilable, until years later somebody realizes
something had not been in use for long times.
More information about the devel