RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather thanjumping to it

[Eric Weddington]

> -----Original Message-----
> From: Joerg Wunsch [mailto:address@hidden 
> Sent: Tuesday, February 13, 2007 1:00 PM
> To: address@hidden
> Cc: 'Anatoly Sokolov'; Eric Weddington
> Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call 
> main rather thanjumping to it
> 
> As Eric Weddington wrote:
> 
> > Joerg, what do you think of this? Time to revisit the atmega256x
> > patch?
> 
> Well, maybe.
> 
> I suggest we change gcrt1.S anyway: if we are not going to place the
> additional infinite loop behind itx, the only cost for doing so is a
> single CALL/RCALL plus the two (or three for the ATmega256x) bytes on
> the stack.  As we already do have compilers around right now that
> treat main() as a normal function, this would simply get us onto the
> safe side avr-libc-wise.

Anatoly, is this ok with you?


> 
> In general, I agree with Anatoly's argumentation.  However, I believe
> the C standard would require main() to be callable, so ideally the
> treatment of main() should be an option, and it should even default to
> being enabled (like we do for -mint8, although the consequences aren't
> so drastic as in the -mint8 case).  In case we should ever implement
> 64-bit floats, I'd also like to see them being the default (for
> standards conformance reasons), with some option (say, -mdouble32)
> to revert to the current behaviour.

Agreed with the 64-bit float behaviour.

> Btw., part of treating main() as a normal function was to remove the
> obsolete initialization of the stack pointer at the beginning of
> main()(when it's actually being already initialized early in .init2).
> I don't know whether that's alredy default GCC behaviour, or also came
> from Bjoern's ATmega256x patch.

Yeah, we need to find out.

> Also, we should certainly ask Bjoern for any comments.

I've forwarded him your email and have asked for comments.

Eric