From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Garnett To: Christian Plessl Cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] GDB Download on i386 target hangs Date: Mon, 09 Oct 2000 06:40:00 -0000 Message-id: References: <5.0.0.25.0.20001005210937.009f18e0@imap.ee.ethz.ch> <5.0.0.25.0.20001006175309.009ee650@imap.ee.ethz.ch> X-SW-Source: 2000-10/msg00083.html Christian Plessl 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