outstanding issues blocking new release?

Christopher Faylor cgf@redhat.com
Tue Aug 7 10:21:00 GMT 2001


On Tue, Aug 07, 2001 at 08:54:20PM +0400, egor duda wrote:
>Hi!
>
>Tuesday, 07 August, 2001 Christopher Faylor cgf@redhat.com wrote:
>
>CF> On Tue, Aug 07, 2001 at 07:32:11PM +0400, egor duda wrote:
>>>Tuesday, 07 August, 2001 Kazuhiro Fujieda fujieda@jaist.ac.jp wrote:
>>>KF> n) Too large cygwin1.dll.
>>>KF> The size of cygwin1.dll suddenly became large when Egor added
>>>KF> the negative index support to ctype_.c in newlib. I guess the
>>>KF> augmented size of the table makes cygwin1.dll so large, but I
>>>KF> can't find the proper way to solve it.
>>>
>>>no. it was because of change of size of zombie array and static buffer
>>>for /dev/dsp. ctype_ change costs only 128 bytes.
>
>CF> Anyone want to handle dsp?  The original developer seems to have given
>CF> up on cygwin.
>
>CF> IIRC, I had to make changes to make sure that the dsp constructor wasn't
>CF> called every time cygwin started.
>
>hmm, i was a bit wrong about /dev/dsp. static buffer is uninitialized,
>so it goes to bss, and doesn't increase the size of dll, it only
>increases the size of mapped address space. i don't think it's good
>either, and feel that buffer should be allocated on heap, and only
>when needed. i'll post a patch shortly.
>
>zombies array wouldn't affect dll size to if it was normal
>uninitialized array. but the problem is that it's NO_COPY, so it goes
>to separate section, and linker doesn't put it into bss.

Too bad that you can only put initialized data in other segments.
It would be nice to have an uninitialized "fork_no_copy" region.

Or, maybe we should only put the stuff that we *want* copied by
fork into its own segment.  Hmm.

cgf



More information about the Cygwin-developers mailing list