Rewrite/fix cygwin1.dbg generation

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
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
problem.

cgf



More information about the Cygwin-patches mailing list