Re: ARM crt.. files

[Philip Blundell <philb@gnu.org>]

>I believe I have devised a solution, but I am too lazy to fully implement
>it myself.  This would replace my postprocessed-assembly kludge with a
>postprocessed-object file kludge, which is probably more portable given GNU
>binutils.  
>
>I don't know if this will actually fly on the ARM, it depends on the
>relocations working the way I am presuming.  But it seems like a good
>direction to investigate.

I've spent some time looking at this and thinking about whether it solves the 
ARM problem.  (Sorry it's taken me so long to get around to it; I've been
rather busy for the last couple of weeks.)

It doesn't fix it completely at the moment.  I think I can see a way to make 
it work but this would involve modifying both GCC and GAS to change the way 
global data is accessed (basically, some of the intelligence would need moving 
from the compiler to the assembler).  Although I'm prepared to try this if 
necessary, I'm not too keen on doing so if a simpler solution would avoid the 
problem.  

The simpler, though less elegant, solution that I can think of is to 
remove the test of `if (__gmon_start__ != NULL)' and always provide a weak 
definition of __gmon_start__ that does nothing.  If the real gmon_start is 
present it will override the weak definition and if not we only have to pay 
the price of one function call at startup, which in any case is offset by
the saving of not needing the comparison.  Does that sound workable and 
acceptable to people?

p.