This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
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: Sat, 9 Jul 2016 17:45:52 +0000
- Subject: 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;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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)