public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gary Thomas <gary@mlbassoc.com>
To: Eric Castle <ecastle@umich.edu>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Bob Koninckx <bob.koninckx@o-3s.com>,
	Ecos-Discuss <ecos-discuss@sources.redhat.com>
Subject: RE: [ECOS] Default CME555 too big
Date: Tue, 08 Jun 2004 21:37:00 -0000	[thread overview]
Message-ID: <1086730634.3643.1710.camel@hermes> (raw)
In-Reply-To: <FHEHIHJPBAMHEPDCEAOGKEDFCAAA.ecastle@umich.edu>

On Tue, 2004-06-08 at 15:19, Eric Castle wrote:
> RE: Too big
> Interesting.  I ran powerpc-eabi-size on my hello.elf program that was about
> 1 MB, and it printed out the following:
> 
> % powerpc-eabi-size hello
> 	text		data	bss	dec	hex	filename
> 	52040		0	16420	68460	10b6c	hello
> 
> Which does seem to indicate a much smaller executable.  I compiled eCos
> without the "-g" flag, and a huge portion of that 1 MB went away.  So I
> guess I shouldn't be having trouble fiting stuff into external RAM.
> 

This is probably the most common error that folks seem to make.  The 
executable file (ELF format) is full of debug and other structural
information.  The actual code+data which needs to be loaded in your
target hardware will be very much smaller, especially if you compile
with -g (the eCos default)

> RE: gdb
> Ack, sorry, yes, I run the load command as well:
> 
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x0000bbe0 in ?? ()
> (gdb) load
> Loading section .text, size 0xa29c lma 0x406000
> Loading section .rodata, size 0x1568 lma 0x4102a0
> Loading section .data, size 0x990 lma 0x411808
> Start address 0x406000, load size 49556
> Transfer rate: 30496 bits/sec, 505 bytes/write.
> (gdb) where
> #0  0x0000bbe0 in ?? ()
> (gdb) jump _start
> Continuing at 0x406018.
> Interrupted while waiting for the program.
> Give up (and stop debugging it)? (y or n) y
> (gdb) where
> No stack.
> 
> 
> I tried both "jump <insert likely sounding function>" and "continue", but I
> never get any output after that point (asides from the one random time it
> stopped at a breakpoint).
> 
> Any thoughts?

"continue" should work - you should not need to "jump" to a special
location.

Try single stepping and/or setting intermediate breakpoints to see
how far along your code is getting.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

      reply	other threads:[~2004-06-08 21:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-08 20:14 Eric Castle
2004-06-08 20:19 ` Andrew Lunn
2004-06-08 21:23   ` Eric Castle
2004-06-08 21:37     ` Gary Thomas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1086730634.3643.1710.camel@hermes \
    --to=gary@mlbassoc.com \
    --cc=andrew@lunn.ch \
    --cc=bob.koninckx@o-3s.com \
    --cc=ecastle@umich.edu \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).