This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: memory corruption problem
- From: "Wilkes, John" <John dot Wilkes at amd dot com>
- To: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Cc: "Wilkes, John" <John dot Wilkes at amd dot com>
- Date: Mon, 11 Jul 2016 16:13:13 +0000
- Subject: RE: memory corruption problem
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=John dot Wilkes at amd dot com;
- References: <BN1PR12MB0004F624C192E8B58FC946B7FF3D0@BN1PR12MB0004.namprd12.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
If _REENT_SMALL is defined, the __sinit(struct _reent *s) function sets s->stdout:
#ifndef _REENT_SMALL
s->__sglue._niobs = 3;
s->__sglue._iobs = &s->__sf[0];
#else
s->__sglue._niobs = 0;
s->__sglue._iobs = NULL;
/* Avoid infinite recursion when calling __sfp for _GLOBAL_REENT. The
problem is that __sfp checks for _GLOBAL_REENT->__sdidinit and calls
__sinit if it's 0. */
if (s == _GLOBAL_REENT)
s->__sdidinit = 1;
s->_stdin = __sfp(s);
s->_stdout = __sfp(s);
s->_stderr = __sfp(s);
#endif
std (s->_stdin, __SRD, 0, s);
If _REENT_SMALL is not defined, where is s->_stdout initialized before the call to __sinit()?
--
John Wilkes | AMD Research | john.wilkes@amd.com | office: +1 425.586.6412 (x26412)
-----Original Message-----
From: Wilkes, John
Sent: Saturday, July 09, 2016 10:46 AM
To: newlib@sourceware.org
Cc: Wilkes, John
Subject: memory corruption problem
I am using a gcc-6.1.0 and newlib-2.4.0 tool chain. FreeRTOS builds with this tool chain and runs all the FreeRTOS demos, so think the newlib port is pretty solid.
However, when running a bare metal program (no OS), I get some memory corruption; a critical variable is overwritten with garbage. I traced the problem to the stdout __FILE pointer.
It looks like the stdout __FILE struct is initialized in _sinit, and "__FILE *_stdout" in the _reent stuct points to the critical variable (i.e. same address). The trashed variable has a fixed address visible in "nm" output, so it doesn't move.
Where in the newlib code is the stdout __FILE struct allocated/created?
This is a new port with primitive debugging, i.e. no gdb support yet, and no shiny eclipse IDE.
Thanks for any help/insight/suggestions!
John
--
John Wilkes | AMD Research | john.wilkes@amd.com | office: +1 425.586.6412 (x26412)