COFF problems

Steve deRosier sderosier@vari-lite.com
Tue Feb 20 10:45:00 GMT 2001


Title: Re: COFF problems



I've had similar problems with trying to get debug info showing up using my HP emulator with an IEEE format.  Basically this is a problem of gcc not retaining file names and paths.  Try looking at a previous series of emails to the cross gcc list:
http://sources.redhat.com/ml/crossgcc/
search on:  crossgcc+debug+with+HP+emulator

Apply the patch that was so helpfully provided.  Also, I created another patch which provides the full path if necessary using a new switch -fkeep-full-file-path.  This was never submitted (I just considered it an unoffical hack that works for me....), but you might find it useful, so I have attached it.

This caused some other problems (a segfault bug) with objcopy and if you run into similar problems try: 
http://sources.redhat.com/ml/binutils/2001-01/msg00306.html   (I think this is the first of the thread, but you are looking for anything in the "binutils/stabs.c fixes" thread.)

Good luck,
- Steve

-- 
Steve deRosier
Embedded Software Engineer
Vari-Lite International, Inc.


----------
From: Girish G <girishg@india.ti.com>
To: binutils@sources.redhat.com
Subject: COFF problems
Date: Tue, Feb 20, 2001, 4:03 AM


Hi, 
I had a few problems with differences between 2 COFF formats for ARM processor, one for Texas Instruments and the other for GNU. My initial problems were posted to  comp.compilers 
My problems have changed a bit but I still have some problems. Going through the original problem would help hence I put that down first 
 
We have two different compiler toolsets, for ARM7-TDMI. One, provided 
by GNU, the other, by Texas Instruments(TI).  We are working on a TI 
chipset having ARM and to work on this, we have a full Windows based 
IDE (code composer studio). Now, we need to write a BSP for this 
chipset to run vxWorks RTOS. We have the Windriver libraries for this 
particular purpose. These libraries have been generated using GNU 
tools, which, unfortunately TI tools refuse to recognize. This we have 
realized to be caused due to differences between GNU COFF and TI 
COFF. We have written a utility to convert GNU COFF to TI COFF 
accordingly. Using this conversion utility on the executable generated 
by GNU tools, we are able to load and run the program using TI 
tools. However, even after this, we are unable to obtain source code 
debug information from the GNU COFF. Could someone please help us on 
this aspect. We need help regarding the differences between the ways 
in which GNU tools and TI tools put debugging information in the 
executable/object files. Please help. 

I have a few pages of interest. I went thru these but could not find 
much information. However, I will put these links here hoping someone 
will find something of help to us 
 

http://www.mit.edu:8001/afs/athena.mit.edu/software/cygnus/cygnus-97r2/www/2_cc/gcc/ccOptions_for_Debugging_Your_Progr.html

Now, we have found that our version of GNU for ARM does not produce file name information when we compile with -gcoff option. 
(gcc driver version 2.7.9-970819 egcs-971225 tornado 2.0 executing gcc version 2.7.9-970819) 
Our tools understand COFF debug format, hence we want this debug format in particular. It also seems as though our tools support DWARF specification but the GNU tools fail to generate debug info in DWARF format. 

(when I try to pass this option, it says 
               cc1: warning: `-gdwarf' not supported by this configuration of GCC 
) 

So, is there any patch for gcc to generate correct debug information with -gcoff flag? Or with -gdwarf for that matter? 

Any other suggestions would also be welcome 

Thanks and regards 
-- Girish 
 
 



full_file_path.patch.gz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: full_file_path.patch.gz
Type: application/octet-stream
Size: 799 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20010220/319748bb/attachment.obj>


More information about the Binutils mailing list