Mail Archives: djgpp-workers/2002/12/19/20:01:49
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.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -