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
