Rewrite/fix cygwin1.dbg generation

Christopher Faylor
Mon Nov 5 11:57:00 GMT 2007

On Mon, Nov 05, 2007 at 12:20:48PM +0100, Corinna Vinschen wrote:
>On Nov  5 10:19, Pedro Alves wrote:
>> Corinna Vinschen wrote:
>> > On Nov  4 04:00, Pedro Alves wrote:
>> > >
>> > > Ah, got it.  VirtualAlloc fails on the first _csbrk, since it
>> > > is tripping on the VMA of .gnu_debuglink ...  I assumed it would
>> > > not be a problem, since it isn't ALLOCced, but oh well...
>> > > I tried adding an EXCLUDE/NOLOAD flag to .gnu_debuglink, but no
>> > > can do.
>> >
>> > That was the reason for creating the .dbg file in the first place,
>> > wasn't it?  The Windows loader appears to allocate the full size of all
>> > sections of the image, including the NOLOAD and DEBUG sections.  Sort of
>> > counterproductive but there seem to be no way around it.
>> >
>> It occurred me that the problem may be that
>> ld is accounting for the virtual address and virtual size of the last section
>> to write the SizeOfImage field in the PE headers, in
>> bfd/peXXigen.c:_bfd_XXi_swap_aouthdr_out.
>> We can change it to not include non ALLOC, DEBUG sections.
>> Anyone tried that already?
>Not me.  It never occurred to me that this could be a problem in ld,
>actually.  If that's the problem and we can fix it, that would be really
>cool.  IIUTC, it would remove the necessity to create a cygwin1.dbg file
>at all.

The real question is if the above is actually doing the right thing wrt
LINK.EXE.  When I was playing with this, I could duplicate the behavior
I didn't want by fiddling with the bits in the sections with Microsoft
tools, bypassing ld entirely.  So, I'm not sure that this is an ld.exe


More information about the Cygwin-patches mailing list