Re: [ECOS] GDB Download on i386 target hangs

[Nick Garnett <nickg@cygnus.co.uk>]

Christian Plessl <cplessl@ee.ethz.ch> writes:

> Hi Nick and others
> 
> >Have you built the test programs in a separate build tree from the
> >floppy monitor? If not, then it is very easy to get
> >cross-contamination and, for example, end up with you executables being
> >linked to the same memory locations as the monitor. The symptoms you
> >describe are consistent with the monitor being overwritten by the
> >download.
> 
> Thanks a lot. You guessed right. Now I've built the tests in a different 
> directory, using a i386 target configuration without stubs (is this right?).
>

Probably not, see later.

> Now I'm able to download the excecutables. But immediately after the 
> download, when I start the program on the target, I get an SIGILL on the 
> target:
> 
> GDB Warning:
> 
> Program received signal SIGILL, Illegal instruction
> 0x3270 in ?? () at /usr/local/pack/ecoscvs/ecos/packages/services/memalloc
> /common/current/src/dlmalloc.cxx:1257

What program are you actually running? Do any of the standard test
programs run? Do not take too much notice of what GDB says the
location is here. It is confused by the address being outside it's
known range and is making a guess.

> 
> It's alway the same address, where the debugger claims to find a illegal 
> instruction. But if I try to disassemble the code at this address in gdb, 
> gdb complains:
> 
> (gdb) disassemble 0x3270
> Error: No function contains specified address.
>

Try "x/1i 0x3270". On my machine this gives

0x3270: fild   (%edx)

which looks like it is halfway through an instruction in the stub
monitor. 


> When looking at the symboltable of the elf binary using nm, there is no 
> code located at 3270.
> 
> I'm somewhat confused and have the following questions:
> 
> a) Do I have to activate gdb stubs for my application?

You have to have GDB stubs included in the executable, there is not
sufficient support in the monitor for it to work. This should
happen by default, unless you have changed the configuration in any
way. Initially, just build the default RAM startup configuration
without changing anything, and make sure that something like the
kernel tm_basic test works.

> b) Whats the matter with this error in dlmalloc? Do I need additional 
> configuration for my dynamic allocatable memory on the heap?
>

As I said above, the problem is (probably) not in dlmalloc, that's
just GDB's guess at where it is.

> 
> A suggestion: Unfortunately there is AFAIK no FAQ on ECOS on i386, but when 
> reading the mailing list, I get the impression, that a lot of people do 
> have some trouble, when starting devolopment with the ECOS on i386. What 
> about collecting these questions and answers in a FAQ.
> 

That would be a good idea.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK