Pedro Alves wrote:
> 10 .cygheap 000a 611e 611e 2**2
> ALLOC
> 11 .gnu_debuglink 0010 6128 6128 001d0a00 2**2
> CONTENTS, READONLY, DEBUGGING
>
> I'll come up with a different fix.
Just thinking out loud here... wh
Christopher Faylor wrote:
If that is the case, then this is a welcome change but I'm wondering if
it really is true. Since the debug stripping is linked to the way that
cygwin manages the cygwin heap, it is possible that things only appear
to work until you allocate more space in the heap. Has
Christopher Faylor wrote:
If that is the case, then this is a welcome change but I'm wondering if
it really is true. Since the debug stripping is linked to the way that
cygwin manages the cygwin heap, it is possible that things only appear
to work until you allocate more space in the heap. Has
On Sat, Nov 03, 2007 at 10:44:26AM -0700, Brian Dessent wrote:
>Pedro Alves wrote:
>
>> The dllfixdbg hunk looks hard to read. Here's what is looks
>> like after patching:
>
>I think that if whatever bugs used to exist in older binutils PE support
>that necessitated this hackery are now gone, we c
Pedro Alves wrote:
> The dllfixdbg hunk looks hard to read. Here's what is looks
> like after patching:
I think that if whatever bugs used to exist in older binutils PE support
that necessitated this hackery are now gone, we can just do away with
dllfixdbg alltogether and just put this:
> ${STR
Hi guys,
As was being discussed at gdb-patches@ [1], the cygwin1.dbg
(the debug info of cygwin1.dll) file misses the section
info of the non-debug sections. Gdb doesn't like that
so much, and issues a few annoying warnings. Previous
versions of gdb had those warnings suppressed at all
times, bu
