This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Huge numbers for incr passed to _sbrk
- From: Michael Mamic <michael dot mamic77 at gmail dot com>
- To: emekamicro at gmail dot com
- Cc: newlib at sourceware dot org
- Date: Wed, 22 Aug 2018 23:19:40 -0700
- Subject: Re: Huge numbers for incr passed to _sbrk
- References: <CAChm1gQqnt-NcO4GG=RKZcHD7HrcFuwLjtDeTupT00Kh0pcXng@mail.gmail.com> <CAOypoo74gb-dU=4rJuqowjPcw0e19WYtypJkGGY38WazMCLCWA@mail.gmail.com>
I have posted the project source up on github.
https://github.com/Mikestylz/CirnOS
On Tue, Aug 21, 2018 at 2:12 PM Emeka <emekamicro@gmail.com> wrote:
> Can you share what you are doing with me ?
>
> On Thu, Aug 16, 2018, 8:31 AM Michael Mamic <michael.mamic77@gmail.com>
> wrote:
>
>> Hello,
>>
>> I am making a bare metal operating system for then Raspberry Pi, using
>> newlib as the standard library. I have implemented all of the syscalls
>> without trouble, the exception being _sbrk which always yields an error.
>> My
>> simple implementation is below:
>>
>> uint32_t sbrk(int incr) {
>> highest_addr+=incr;
>> if(highest_addr > 0x20000000) {
>> errno = ENOMEM;
>> return -1;
>> }
>> return highest_addr;
>> }
>>
>> This implementation of sbrk is seemingly fine, but sbrk itself is called
>> with an incredibly large value for incr, 1431656813. This huge number
>> causes my memory to immediately overflow. After debugging, I have found
>> with almost absolute certainty that this call to sbrk comes when I call
>> printf, sometime before the text is sent to _write for dislay. My
>> installation of newlib comes from the libnewlib debian package, and it is
>> on the most recent update.
>>
>> What could be the problem here, and is my implementation of sbrk adequate?
>>
>