This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: crt0 formalization
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jeff Johnston <jjohnstn at redhat dot com>
- Cc: jschopp <jschopp at austin dot ibm dot com>, newlib at sources dot redhat dot com, Ben Elliston <elliston at au1 dot ibm dot com>
- Date: Mon, 04 Dec 2006 14:32:34 -0600
- Subject: Re: crt0 formalization
- References: <45705F86.7040406@austin.ibm.com> <45746C8B.5040908@redhat.com> <45746DF3.30102@oarcorp.com> <457483E4.2060307@redhat.com>
Jeff Johnston wrote:
It's for the spu. I am guessing that Joel also got an error message
regarding the patch size so it never got posted to the newlib msg
list, though it made it to my inbox.
That definitely looks like the case.
I have tar'd up the patch and attached to this message.
Thanks.
Since this is SPU specific, I assume it is correct for that. But I
wonder why crt[in].S are included
in newlib. Normally they are in gcc.
--joel
-- Jeff J.
Joel Sherrill wrote:
Jeff Johnston wrote:
<resent due to sources.redhat.com rejecting my original reply
message due to the fact it included the original patch and thereby
exceeded a size constraint>
Is it fair to say no one has objections to this patch? I will check
it in later today unless I hear otherwise.
I don't remember seeing this patch and I don't see any email from
jschopp or a message with
"formalization" in the subject in the newlib mailing list archives
for the past few months .
It may be fine but I don't think it has been seen on the newlib list.
Which platform is the crt0 for?
--joel
-- Jeff J.
jschopp wrote:
In our recent SDK 2.0 and in patches being submitting for FSF gcc
there are some changes to crt0. The attached patch has been
extensively tested as part of our SDK. Everything works as
expected. The only minor regression is that it pulls in atexit(),
which in turn pulls in malloc(). This works fine but takes up
space, which is precious on this platform. Previous discussions on
this list have sent some patches with resolve the problem of
pulling in malloc.
In my opinion the attached patch should be committed.
------------------------------------------------------------------------