This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Looking to contribute OMF support
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Mar 14, 2006 at 11:58:20AM +0000, Nick Clifton wrote:
> Attached. / Right. / I think that the FSF might even use faxes....
Great, thanks for that!
> >NOT working or untested:
> > - linking of more complex modules
> > - objcopy
> > - assembler output
> >
> >I hope that's good enough for an otherwise nonexistent port?
>
> Yes. Ideally however it would be nice if there was sufficient code to
> allow the port to be tested. Ie supporting assembler output would
> really be a good idea.
Seems to me BFD_JUMP_TABLE_WRITE has only one substantive method
(_bfd_set_section_contents) but for anything interesting I'll have to
figure out how to write relocs to the output file. Do I do that from
within _bfd_set_section_contents too?
> If this is something that you are planning to add in the future then
> this is fine, but if not, then how can we, the binutils maintainers,
> tell if your code is still working ? We test the code all the time
> and we try to make sure that it all works. We also have a process
> whereby we retire unsupported and no-longer-working ports. If we
> cannot test your port, how can we make sure that future changes to the
> generic parts of the binutils sources do not break the OMF port ?
I won't make any promises about contributing zillions of patches but as
long as you don't uncover rocket science bugs I may have written I'm
sure you can gently bully me into fixing stuff when it breaks. :)
Are there any things specific to BFD that I can do to make my code more
or less resilient to bit rot? One thing I'm worried about that I
thought was okay, is that I bfd_alloc gobs of memory everywhere without
freeing them, relying instead on bfd_close to release the memory when
objdump et al are done with the BFD. But then I saw a recent message
that seemed to say that that constituted a memory leak...
Another general question I have is about "segment groups" in the DOS
world. OMF objects already specify a mapping from input sections
("segments") to output sections ("groups") and I don't have the foggiest
where to begin teaching the linker to understand these GRPDEFs if I
wanted to. Any ideas? As a last resort one could probably generate a
linker script as a separate step between assembly and linking, where a
script would fish out the GRPDEFs from objdump -p and rewrite them as,
say, DGROUP : { foo.obj(BSS.1) foo.obj(DATA.1) } etc.
- --
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/
iD8DBQFEFsTWwyMv24BBd/gRAkkmAJ9IHaPBzqxYSN0yj742DGiQDeX0LQCgjHJs
IhkGXFVm5vXysUKVSeRN++k=
=AOe/
-----END PGP SIGNATURE-----