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


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Mar 16, 2006 at 08:53:32AM +0000, Nick Clifton wrote:
> >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.

In that case I won't feel too guilty about it.  I would "no longer need"
the string tables and section data when I "no longer need" everything
else, i.e. at program exit.

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

Something like that.  In that crazy segment:offset world you may want to
define your stack and default data segments as separate sections, in
order to have separate name spaces for the symbols therein, but you want
16-bit pointers to be able to point to any object in either of them, so
they need to be grouped into the same "group".  I think what ELF calls
"sections" the DOS world would call "segment", and ELF "segments" are
"groups".

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

Thanks for the pointer, that looks just about exactly like what I want!

- -- 
/"\  ASCII Ribbon Campaign - against html email
\ /                        - against microsoft office attachments
 X                         - against text above fullquote below
/ \                        - against lines longer than 79 characters
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/

iD8DBQFEGUhzwyMv24BBd/gRAn13AJ487YZieuA4M7fJtLuS2evdbCzr+gCfaQ6W
N9JFOBGPpwzMQrGsvxB/il0=
=RZQY
-----END PGP SIGNATURE-----


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