This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [Arm] SP and SL initialization refactored
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Alexander Fedotov <alfedotov at gmail dot com>, Nick Clifton <nickc at redhat dot com>, Tamar Christina <Tamar dot Christina at arm dot com>, Newlib <newlib at sourceware dot org>, nd <nd at arm dot com>
- Date: Wed, 10 Apr 2019 15:55:31 +0100
- Subject: Re: [Arm] SP and SL initialization refactored
- References: <CAN8C2Cp_c=fQyqG-wMfU5wavz2a-4940Lqa3Vvdw+iz3TYhUqw@mail.gmail.com> <ee9c8cbb-6c6d-3ab8-b018-786f747c1efb@arm.com> <20190410142353.GI4248@calimero.vinschen.de>
On 10/04/2019 15:23, Corinna Vinschen wrote:
> Hi Richard,
>
> On Apr 10 13:26, Richard Earnshaw (lists) wrote:
>> On 19/03/2019 13:54, Alexander Fedotov wrote:
>>> Hi all
>>>
>>> In continue of threads
>>> https://sourceware.org/ml/newlib/2019/msg00117.html and
>>> https://sourceware.org/ml/newlib/2019/msg00102.html
>>>
>>> I have reworked stack pointer initialization and stack limit as well.
>>> General idea behind of all these changes is to provide hook for
>>> flexibility (including semihosting when debug tap is used) and improve
>>> readability of existing crt0 code.
>>> And now code makes SP initialization in Thumb mode :)
>>>
>>> Any comments are very appreciated.
>>>
>>> Alex
>>>
>>
>> Apologies once again for the delayed review.
>>
>> A small plea: when posting patches, please can you ensure that your
>> attachments are text/patch, or something similar, so that replies will
>> include the contents (and I can view them directly in the email rather
>> than having to mess about extracting the attachment).
>
> Ideally the patches are inline patches sent with `git send-email' or
> equivalent. I added some wording in terms of how to provide patches to
> https://sourceware.org/newlib/ lately. Do you have a suggestion for
> improving this?
>
>
> Thanks,
> Corinna
>
Not really; When I use git format-patch with --attach I get
text/x-patch as the MIME type, which is fine. Problems only start if
users have poorly configured mail client that attach as octet-stream or
other binary types. Then mail clients can't display the attachment
inline as they don't know the format is really displayable.
R.