This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Looking to contribute OMF support


Bernd Jendrissek <berndj@prism.co.za> wrote in
news:20060310140046.GA11152@prism.co.za: 

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all
> 
> It seems my employer should be willing to assign copyright for the OMF
> support I've added using (in part) company time and equipment, to the
> FSF.  I'll need one of those pre-paperwork-preparation forms that I've
> seen around here regularly; would somebody please send me one of
> those? Private email or here is fine.
> 
> Since this will be certainly my, and likely the company's, first such
> submission, I'm a little daunted by the length (time) of the
> procedure. I need to fill in a form for requesting the real form,
> right?  Is it only the second set of forms which have to cross the
> ocean by snail-mail?
> 
> As for the OMF support itself:
> 
> I wrote the object file format support against .OBJ files produced by
> TopSpeed C 3.10, which AFAICT is supposed to be compatible with the MS
> (and Borland too, probably) tools of the era, except that it defines a
> few comment records for specifying dependencies, and defines multiple
> sections with the same name (not sure how kosher that is to other
> OMF-aware tools).
> 
> I didn't bother trying to write complete support, and I can't even
> guarantee that I interpret records correctly either; this is one of
> those "it works Well Enough For Me for what I want to do with it"
> ports. 
> 
> Notably, what works WEFM is:
>  - section dumping and disassembly and of course 'size' which was my
>    scratch to my itch of wanting to know which modules needed the most
>    memory
>  - listing of symbols and relocations (OMF relocs are hell, expect
>  bugs) - surprisingly to me, ld was able correctly to locate a tiny
>  dummy 
>    module that contains "offset16" relocs.
> 
> NOT working or untested:
>  - linking of more complex modules
>  - objcopy
>  - assembler output
> 
> I hope that's good enough for an otherwise nonexistent port?  (I'd
> prefer to show-and-tell once the paperwork is done.)
> 
> - -- 
> You're proposing to build a box with a light on top of it.  The light
> is supposed to go off when you carry the box into a room that has a
> Unicorn in it.  How do you show that it works?
>          - Dr. Gene "spaf" Spafford, at Dr. Wenliang Du's qualifing
>          exam 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Please fetch my new key 804177F8 from
> hkp://wwwkeys.eu.pgp.net/ 
> 
> iD8DBQFEEYZfwyMv24BBd/gRAnE7AJ48CJ7ceIk+aDn9kIY8FEx40wD7FACdG5hD
> dWN1uFxt4Lx42iTcJagxtTc=
> =Owyj
> -----END PGP SIGNATURE-----
> 

This thread is kind of old but I was wondering whatever happened to this
endeavor of hacking OMF support into libbfd. Did it ever come to
fruitation? 

I'm looking for borland/delphi source debugging support with gdb and
came across this thread. If OMF support is fully implemented into bfd,
would anything more have to be done to get source level debugging to
work in gdb for executables/dll's compiled with something other than
gcc? Specifically compiles that emit OMF symbolic debug info like
borland c++ build. I beleive Digital Mars Compiler emits OMF symbolic
info as well. 

Thanks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]