[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PPC initialization (SYSV-ABI/EABI/C++ issues).
- Date: 13 Feb 2003 21:44:32 +0300
- From: osv at javad.ru (Sergei Organov)
- Subject: PPC initialization (SYSV-ABI/EABI/C++ issues).
till <strauman at slac.stanford.edu> writes:
> Thanks for shedding some more light on this. Could you clarify some more
At least I can try to :-)
> - R13 should be set up regardless of RTEMS using EABI or SYSV, right?
> *** even if RTEMS is considered to be non-EABI, most BSPs are probably ***
> *** broken as they currently fail to setup R13. ***
No, I don't think so. By default ppc-rtems-gcc produces code that doesn't use
R13 to access variables in the .sdata/.sbss, though it does put variables of
the size less than or equal to 8 bytes to these sections.
> - it seems to me that R2/R13 don't really have to be set before _any_ C
> code is executed but they must be set before any code compiled with
> -msdata=eabi/sysv/use is called.
Yes, indeed. For simplicity I've supposed that all the C/C++ code is compiled
with the same flags, that's why I said "any".
> - the current behavior (RTEMS calling __init from the ThreadHandler) is
> wrong. An application using main (and hence calling __eabi) has C++
> constructors called twice.
Yes, I think so.
> - substituting __init in ThreadHandler by __eabi is wrong but it should work
> as long as RTEMS does not _use_ R2 or R13 prior to executing __eabi.
Yes. But much simpler fix, IMHO, is just to provide empty __eabi() (e.g., in
start.S) instead of substituting __init by __eabi. Though unlike substitution
it won't initialize r2/r13 at all, the "calling constructors twice" problem is
> - the proper sequence would be:
> [0) if the relocation features are needed, relocation has to be
> performed first ]
> 1) initialize R13 / R2 (using linker magic as you proposed) as early as
> 2) initialize newlib
> 3) call C++ constructors once ( __init from ThreadHandler)
> 4) prevent app 'main' from calling __eabi
Or provide empty __eabi().
> That way, RTEMS itself and/or newlib could even benefit from the short
> data areas (requires building with -msdata=eabi or sysv)
> NOTE: all of this can easily be achieved if __eabi can be prevented from
> branching to __init. The BSP would then just call __eabi() at an early
> stage and the ThreadHandler calls __init as it has always done.
Yes. I even think it'd be the best solution to fix gcc/config/rs6000/eabi.asm
so that it has a separate global routine that performs low-level part of what
__eabi() currently does. For compatibility, __eabi() itself could then just
call this routine and then __init(). RTEMS will then arrange to never call
__eabi(), and BSP will call this new low-level initialization routine ASAP,
and then __init() from ThreadHandler.
If it's not an option to change gcc, then PPC port can provide its own
low-level initialization routine that will be called by all BSPs start.S files
(the routine may also include such common things as cleanup of .bss/.sbss and
copying of .data from ROM to RAM).
> - do you see any other difference between -meabi and -mno-eabi besides the
> stack alignment requirement?
I talked about differences between '-meabi' and '-mno-eabi -msdata=eabi'. As
far as I remember, besides stack alignment, alignment of doubles also differs,
8 vs 16, respectively. The weaker alignment requirements of -meabi could
result in performance degradation on PPCs with 64-bit data bus when accessing
doubles, I think, but I don't have any numbers. On the other hand, weaker
stack alignment has potential benefit of more conservative stack usage.
> Is there any problem in real life resulting from misalignment?
Yes, when one passes a lot of arguments to a C routine and they begin to be
put on stack, there could be problems. I myself once found related problem
when RTEMS didn't align task stacks properly. The problem occurred when
printf() with a lot of arguments has been called.
Overall, I'd afraid to mix code with different alignment requirements in a
> The way I see it now (given the fact that some changes, even in the
> toolchain, are necessary anyways), it seems that RTEMS should be declared to
> support EABI (as Joel proposed). Hopefully the multilib jungle can be
> reduced somewhat.
It's my opinion as well.