This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Huge numbers for incr passed to _sbrk
On Fri, Aug 24, 2018 at 2:16 PM, Michael Mamic <michael.mamic77@gmail.com>
wrote:
> I have fixed the bug now. It turns out that I was using uint32_t types for
> my sbrk implementation when I should have been using char* types. The
> official Newlib documentation uses caddr_t in its sample implementation of
> sbrk, which was confusing to me as that is a type I had never seen before.
> I had to browse through a forum from 1999 to figure out that caddr_t is
> just a typedef to char*.
>
> I think it would help all new users of Newlib if the documentation used
> char* instead of caddr_t, or at least had a sentence saying what caddr_t
> is.
>
The default typedef is in newlib/libc/include/sys/types.h. Some OSes
define it themselves. caddr_t seems easy to find. Which seems irrelevant
since sbrk() is prototped in sys/unistd.h as:
./sys/unistd.h:void * _sbrk (ptrdiff_t __incr);
Looks like there are a fair number of incorrect types in the various sbrk
implementations in libgloss.
Where did you find your sbrk() starting point?
And was there not a mismatched prototype warning when you compiled it?
--joel
>
> On Thu, Aug 23, 2018 at 1:52 PM Bob Dunlop <bob.dunlop@xyzzy.org.uk>
> wrote:
>
> >
> > On Thu, Aug 23 at 10:22, Michael Mamic wrote:
> > > A similar incr value of huge proportions is passed to sbrk when Lua is
> > > initialized. I need to find out why this is happening so I can adjust
> for
> > > it.
> >
> > Are the library and syscall implementation being compiled with the
> > same compiler flags and using a common header file for the function
> > prototype ?
> >
> > A mismatch in type or parameter passing conventions between caller and
> > callie could lead to these sorts of errors. But then I'd have expected
> > just about every function to be affected.
> >
> > The value seen in the syscall 1431656813 converted to hex is 0x5555596D.
> > Now all those 5s make me think of stack or memory boundry guard values.
> >
> > --
> > Bob Dunlop
> >
>