FW: problems with objcopy

["Steve deRosier" <sderosier at vari-lite dot com>]

Binutills List:

I am forwarding this in the hopes that someone else here can help Ganesh.
I've helped as much as I can, but these errors are beyond me (at least
without spending a significant amount of time staring at code and
debugging).  Hopefully someone with Objcopy experience can help.

- Steve

----------
From: "Tawde, Ganesh" <gtawde@opentv.com>
To: "'Steve deRosier'" <sderosier@vari-lite.com>
Subject: RE: problems with objcopy
Date: Mon, Aug 6, 2001, 2:17 PM


Hi Steve,

I included the pathces you recommended (except the full file path patch) and
rebuild the cross compiler. I am still facing some problems with objcopy. I
have a library which is compiled using MRI cross compiler, but I dont have
the sources for it. All my files compile fine, but in the link phase I get
an error saying

     0 [main] m68k-coff-ld 282 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
  47180 [main] m68k-coff-ld 282 open_stackdumpfile: Dumping stack trace to
m68k-coff-ld.exe.stackdump
This crash occurs in file reloc.c, line 611, function
bfd_perform_relocation( ... ) when debugged using gdb. This could be becasue
I am trying to link a ieee format library.

So I try to first convert the library to COFF format using m68k-coff-objcopy
-O coff . But I again get a segfault error in objcopy. When I debug the
m68k-coff-objcopy.exe using gdb, I find that the executable crashes at line
2261 in file coffcode.h (?), function coff_write_relocs(..).

I am looking and trying to understand what could be happenning, but do you
have any idea about the causes ?

Thanks
Ganesh

P.S.- Is it possible for you to send me your m68k-coff-objcopy executable so
that I can try it over here to verify whether I am messing up something
during cross compiler build ?

-----Original Message-----
From: Steve deRosier [mailto:sderosier@vari-lite.com]
Sent: Friday, August 03, 2001 9:24 AM
To: Tawde, Ganesh
Subject: Re: problems with objcopy

Sure, I will send a separate email with the patch in the body of the message

Ok, our switch included not only getting the GCC stuff compiled and working,
but also consisted of considerable changes to our code since we were relying
on several MRI-specific things that GCC either doesn't have or does in a
different way.  Our general procedure for making a project was:

* compile .c, .cc; assemble .a files to get object (.o) files using
m68k-coff-gcc and m68k-coff-as
* if the .o goes in libraries then those are put in there by m68k-coff-ar
(don't convert to IEEE yet)
* on the other hand if we have a project that generates an executable, use
m68k-coff-ld to link both the .o and the libs
* then use objcopy to convert the final executable to IEEE and/or srecords.

Assuming you have the source of the libraries that were created with MRI
tools, you should rebuild those using the GCC tools.

For a more concrete example: most of our projects are split into three
parts:
+ The OS.  Stored in a library and linked into almost all of the projects
+ FPC.  This is a library that contains code that is common to most of the
projects.  Really has the bulk of the executable code for any project.
+ Project Code (PC).  This is the actual code that is specific to the
hardware or otherwise unique to that particular system.  Also, this has a
linker command file to build the final executable.  This linker file loads
the OS.lib and FPC.lib to get at the appropriate code that it uses.

Each part has its own make file.

In general the procedure is this:
* run make on OS.  This compiles all OS source from assembly, C, and C++
into individual .o files.   These are then collected into our OS.lib by
using m68k-coff-ar.
* run make on FPC.  Same deal as with OS, compiles the source and puts it
into  FPC.lib
* run make on the project PC.  This compiles all the PC source into .o; then
links all of the PC .o with OS.lib and FPC.lib and makes a final executable
which is then converted via objcopy into IEEE and srecords (yes, we need
both, but you might not).

BTW, if what you are using from MRI is just generic C/C++ libraries, startup
code, etc, you should get newlib (link on gnu.org) and use that if you
aren't already.  After you get those and build them you can throw away the
MRI lib.

- Steve

----------
From: "Tawde, Ganesh" <gtawde@opentv.com>
To: "'Steve deRosier'" <sderosier@vari-lite.com>
Subject: RE: problems with objcopy
Date: Thu, Aug 2, 2001, 4:55 PM


HI Steve,

thanks so much for your explanation. I will try them. Somehow, I am not able
to open the zip file. Could you please send it to me again in raw zip format
rather than gz or anything else. Also, could you please brief me about the
steps you followed to switch over from MRI to GCC ? I am doing the
following.

- compile .c files using m68k-coff-gcc -c . We get .o files
- convert the .o files to IEEE format using m68k-coff-objcopy -O ieee. If I
use --debugging, I get segfault.
- create a couple of libraries from the .o files using m68k-coff-ar.
- Link the libraries together using m68k-coff-ld. I have some other
libraries which are created using the MRI tools and an MRI linker script.

Are these OK ? Do I need to change anything ?

Thanks
Ganesh
-----Original Message-----
From: Steve deRosier [mailto:sderosier@vari-lite.com]
Sent: Thursday, August 02, 2001 1:34 PM
To: Tawde, Ganesh
Subject: Re: problems with objcopy

Ganesh,

Not a problem!  I will warn you though, I'm not really an authority on
Binutils  or GCC, I've only used them to cross-compile for our embedded
systems.  In that project I did get pretty familiar with the tools and even
had to patch them a bit, so I will try to help as I can.

First, the segfault....  This is most likely the same problem I ran into.  A
discussion of it is at:
http://sources.redhat.com/ml/binutils/2001-01/msg00306.html

Or the whole thread "binutils/stabs.c fixes":
http://sources.redhat.com/ml/binutils/2001-01/threads.html#00306

As far as the first part of your question...I don't have any specific
answer.  I never ran into the problem, but at that point I was using all
GCC/Binutils tools instead of the MRI tools.  If you don't absolutely have
to use the MRI librarian, I would recommend that you use the Binutils
version of it.  It is called "ar"  (short for 'archive').  One thing that
may or may not help is getting GCC/Binutils to preserve the filenames/paths
(it doesn't but the MRI tools do).  Go to:
http://sources.redhat.com/ml/crossgcc/
and 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
unofficial hack that works for me....), but you might find it useful, so I
have attached it.

I think you need to do these patches before making the segfault fix.  And
you need to do the patch mentioned in the archives before the one I just
sent you.

But overall, I would recommend you only working with one tool set if you
can.  Use the GNU stuff ONLY or the MRI stuff ONLY.  Mixing them can cause
problems (as you have experienced).  We currently use the MRI tools here for
our embedded work (we make lighting consoles and fixtures for the
entertainment industry).  The GCC stuff was a project I worked on for awhile
to see what it would take to move over to using it instead of the MRI (MRI
costs us $$ while the GNU stuff doesn't).  It works and we could move over,
but using GCC did bloat our executables, so we decided to stick with the MRI
stuff for now (besides, the time to port everything over is significant and
we don't really have a spare programmer just sitting around anywhere!).  The
real problem is no one is maintaining the m68k parts of GCC other than to
make sure they work, ie they are not as well optimized as other parts.  Sad
considering that the M68000 was the first chip supported by GCC...

Anyway, all that said, good luck.  Let me know if there is anything else I
can help with.
- Steve
--
Steve deRosier
Embedded Software Engineer
Vari-Lite International, Inc.
http://www.vari-lite.com/

----------
From: "Tawde, Ganesh" <gtawde@opentv.com>
To: "'sderosier@vari-lite.com'" <sderosier@vari-lite.com>
Subject: problems with objcopy
Date: Thu, Aug 2, 2001, 2:01 PM



Hi Steve,

Sorry for sending email to you rather than to the list but I am having
problems sending emails to the list. The mails are bouncing back. I found on
the mailing list that you have done something similar to what I am doing. I
would appreciate if you could help me in this. Below is the email I sent out
to the list before.

Thanks
Ganesh

I am having some problems using objcopy.
1) m68k-coff-objcopy puts some file identifiers int he object modules
instead of using the file names when converted from COFF to IEEE format -
say it puts st000345 for file abc.o. I am compiling multiple files and
converted them to IEEE format. When I try to create a library using these
object modules using Microtec LIB68K librarian, I get errors for some
modules saying that they already exist even though the library is a newly
created one. After investigating I found that objcopy assigns same names to
two or more different object modules and so the librarian gives errors. Why
does objcopy use these unusual names instead of the fiel names themselves ?
Hos can we have those names to be unique ? Any idea ?

2) With the command line "m68k-coff-objcopy -O ieee --debugging file.o" I
get the following error
0 [main] m68k-coff-objcopy 414 open_stackdumpfile: Dumping stack trace to
m68k-coff-objcopy.exe.stackdump
Segmentation fault (core dumped)
any fix for this or any suggestions how I can fix this ?
This happens even though I use all GNU tools. I got the following error
while converting the library created by m68k-coff-ar to IEEE format using
command line

m68k-coff-objcopy -O ieee bcd.lib

BFD: bfd assertion fail ../../binutils-2.10.1/bfd/ieee.c:1996
0 [main] m68k-coff-objcopy 414 open_stackdumpfile: Dumping stack trace to
m68k-coff-objcopy.exe.stackdump
Segmentation fault (core dumped)

Any help ASAP would be highly appreciated.

Thanks
Ganesh