[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] problems on linux

From: E. Weddington
Subject: Re: [avr-gcc-list] problems on linux
Date: Tue, 31 May 2005 12:16:24 -0600
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Kitts wrote:

I then tried compiling for the mega128 and nothing would work! I
then thought i needed to debug on a simulator and discovered that
"make coff" or "make extcoff" returned errors. Now the interesting
part is that all of what i tried work fine when using Winavr on
The ELF to COFF convertor is only available on WinAVR as it is only
used by Atmel's AVR Studio which is a Windows-only program. For
debugging on Linux, use GDB + simulavr.

Oh! i did not know this. How then to use VMLAB which expects coff files? Since i was planning to use VMLab. But i guess the code size would be greater than VMLAB would permit. I do not know how to use simulavr hence i have not tried.

Oh, I wasn't aware that you're using VMLab. That is a lot better than simulavr.

There is a source code patch to GNU Binutils (2.15) that adds the ELF->COFF convertor, but you'll have to build binutils from the source. Let me know off-list if you want the patch.

Does anybody have a clue of what could be the problem? I seek your
Not offhand. Probably the FreeRTOS folks would have to take a look at
what's going on.

I have been in discussion with Richard Barry of FreeRTOS but neither of us could figure it out. With him attempting on windows using Winavr he said "It seems that although the asm code generated is basically the same (labelnames are different so could possibly also have different addresses) the debug information format is different. I can see the path names in the .elf file, but trying to open it in the simulator it just says "the object code file does not contain source code information". Maybe because the Windows version does not like Linux style file paths? Although it should be able to use either format."
Hmm. That could be. Many Windows software does not hanle Linux/Unix paths correctly. But I would suggest reviewing the assembly output rather than relying on anything in the debugging information.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]