On 30-3-2011 19:26, Ian Lance Taylor wrote:
Why do ecrti.o and crtbegin.o cause trouble? Are you assuming that your
code is the very first in the file? If that is the problem, I would
recommend adjusting your linker script to put your vector table at the
front. I think that will be simpler than fighting against the compiler
here.
Thank you for your response. I had indeed assumed that my code would be
the first to appear in the file. I had placed the start of the vector
table at the start of the .text section by passing the object with the
vector table as the first argument to the linker. Unfortunately, ecrti.o
and crtbegin.o were prepended to the .text section by the compiler and
thus moved the vector code.
The trouble caused by these files stems from the fact that their code is
executed without proper context. Imagine the following as the first code
executed after a cold boot (at which point neither r0 nor r1 contain
valid values yet):
00000000 <__do_global_dtors_aux>:
0: 94 21 ff e8 stwu r1,-24(r1)
4: 7c 08 02 a6 mflr r0
8: 93 e1 00 14 stw r31,20(r1)
I'd initially tried to use the linkerscript, but ran into some issues
(which have now been fixed) thus prompting me to experiment with
-nostartfiles. But the whole thing had made me wonder how these files
(ecrti.o and crtbegin.o) were intended to be used.. they are now
basically dead code as far as my application is concerned; I don't call
any of the code in these files since I don't need C++ support.
Is this the intended manner to implement this - tweak the linkerscript
or use -nostartfiles (and provide your own EABI definitions) - or how
does one go about this for OS-less C-only targets?
Ian
--
With kind regards,
Met vriendelijke groet,
Marco Awater
Software Engineer
------------------------------------------------------
AcQ Inducom, the Netherlands
T: +31 412 641922 / F: +31 412 622640
Email: marco.awater@xxxxxx / Web: www.acq.nl
people inventing technology
creating systems serving people >>>
------------------------------------------------------
