This is the mail archive of the
mailing list for the newlib project.
Re: first post, perplexed by printf()
- From: Jeff Johnston <jjohnstn at redhat dot com>
- To: Dave McGuire <mcguire at neurotica dot com>
- Cc: newlib at sourceware dot org
- Date: Wed, 8 Oct 2014 18:06:38 -0400 (EDT)
- Subject: Re: first post, perplexed by printf()
- Authentication-results: sourceware.org; auth=none
- References: <542E1B16 dot 8050503 at neurotica dot com> <542E4C7D dot 3030500 at op dot pl> <5433E587 dot 6060305 at codesourcery dot com> <5435681B dot 7040500 at neurotica dot com> <54357CDC dot 8070400 at codesourcery dot com> <54358C81 dot 2040303 at neurotica dot com>
A failure that occurs by making a slight code modification can sometimes indicate an invalid storage access
has occurred. Assuming that your code is more complex than just a single printf, have you tried running your code
through Valgrind to see if you perhaps have any such items as uninitialized pointer reference, array bounds
issues, or referencing freed storage? Perhaps something is relying on malloc'd heap storage being clear.
Can you verify that the .bss area is cleared properly for your tool-chain at start-up?
-- Jeff J.
----- Original Message -----
> From: "Dave McGuire" <firstname.lastname@example.org>
> To: email@example.com
> Sent: Wednesday, October 8, 2014 3:12:01 PM
> Subject: Re: first post, perplexed by printf()
> On 10/08/2014 02:05 PM, Jonathan Roelofs wrote:
> >>>>> If I do printf("%d\n", 1); everything works fine. If I do
> >>>>> printf("%d\n", 10);, my processor hangs. (again with no debugging
> >>> Pointed question: where did you get your implementation of
> >>> __aeabi_divmod?
> >> Well I certainly didn't write it. ;) Isn't that in libgcc?
> > Yeah, that comes from libgcc. The pointed question was aimed at whether you
> > were
> > using the one from llvm's compiler_rt, which had a bug which has
> > subsequently
> > been fixed, that manifested itself in a similar manner. But since you're
> > not
> > using that, it's probably not the same problem.
> Nope, not that. Thanks for the thought, though!
> > When your processor hangs, can you tell if it's hitting an interrupt, and
> > if so
> > which one?
> I haven't looked that far yet, but on a lark I just tried the
> "official" gcc-arm-embedded toolchain, and my (unmodified) code runs,
> with my linker script and startup code...so there's something wrong with
> my toolchain.
> "Dang these guys and their broken home-built toolchains!" ;)
> (It has worked wonderfully for many years on dozens of projects, but
> this is the first time I've targeted a thumb-only processor, so it's
> gotta have something to do with that.)
> So that "official" toolchain looks to be Cortex-only, oddly, which is
> a problem for me.
> I'll go digging through their build scripts to see if I can figure out
> what's going on.
> Dave McGuire, AK4HZ/3
> New Kensington, PA