Re: Looking to contribute OMF support

[Nick Clifton <nickc at redhat dot com>]

Hi Bernd,

> Are there any things specific to BFD that I can do to make my code more
> or less resilient to bit rot?

Sorry - not really.

> 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...

Well it does, but it is not a serious memory leak.  As a general 
principle it is always best to explicitly free any memory that you 
allocate, as soon as you are sure that you no longer need it.  But 
sometimes knowing when the memory is no longer needed is difficult to 
decide.  The only real problem with memory leaks is if they prevent 
programs from running, and this is unlikely for most situations you will 
encounter whilst programming the binutils.

> 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.

So these GRPDEFs are present in object files, but are only intended to 
be used when creating executables ?

It sounds to me like you might want to use some of the linker's 
emulation routines.  Have a look at ld/ldemul.h and the function 
create_output_section_statements().  You might be able to define this 
function for your OMF backend and have it scan for GRPDEFs in the input 
bfd's and then synthesise DGROUP definitions as you showed above.

Cheers
  Nick