delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/12/19/12:17:22

From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10212191719.AA12270@clio.rice.edu>
Subject: Recommended restructuring
To: djgpp-workers AT delorie DOT com (DJGPP developers)
Date: Thu, 19 Dec 2002 11:19:21 -0600 (CST)
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

I'm looking at what's needed to make sure libc is more modular, which
would allow us to make it shared or allow users to replace pieces 
more easily.  I think it's important that we make these changes ASAP.
In particular, certain key modules (such as crt0.S) use variables 
they don't define - and they are defined in large modules you would
prefer to separate.

1) Move definition of __djgpp_ds_alias from go32/exceptn.S to crt0.S 

   Why? crt0.S creates and destroys this selector, and manages it 
   in the sbrk() routine.  It was historically in exceptn.S to allow
   us to do a single locked memory area (all in .text) instead of
   multiple ones; but exceptn.S is merely a user of this variable.  
   It's time to fix this.
   
   It's a core variable also used by __dpmi_int.  Images can actually
   be built and run without exception support - but we currently can't
   do that because the key variable __djgpp_ds_alias forces you to
   bring in all the exception handling.
   
   This will require an additional lock call in the exception setup.
   
2) Move definition of _crt0_startup_flags from crt0/crt1.c to crt0.S

   crt0.S references this variable 12 times; crt1.c doesn't reference
   it at all but defines it and is a large module.
   
3) Move setup of _dos_ds from crt1.c to crt0.S; separate from go32_info_block

   It was originally there; it's destroyed there.  It's needed by
   almost everything (will be needed to do the initial libc load).
   Proposal is to have a crt0.S variable which stores it; the crt1.c
   routine will copy from this variable to go32_info_block (crt0.S
   doesn't need go32_info_block except to get this value to free it).
   
   At the very least the setup needs to be in a separate module from
   crt1.c and can deal with being called from crt0.S

Additional items I've noticed, but probably aren't strictly required are
to break up crt1.c and dpmiexcp.c into separate modules (right now it
appears those routines would end up completely in libc.dxe anyway).

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019