Message-ID: <3E021EA4.E3FC5262@yahoo.com> Date: Thu, 19 Dec 2002 14:31:48 -0500 From: CBFalconer Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Recommended restructuring References: <10212191719 DOT AA12270 AT clio DOT rice DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Charles Sandmann wrote: > > 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). I am speaking from total ignorance here, but these things sound as if they should be protected. While they may be needed for reference elsewhere, it might be wise to provide a function or functions to expose their values, without any possibility of external code disturbing them. -- Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net) Available for consulting/temporary embedded and systems. USE worldnet address!