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

[E. Weddington]

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
> > > windows.
> > >      
> > 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
> > > advice!
> > >      
> > 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.

Eric