Christopher Faylor wrote:
Is there some reason why you can't just put the '-R' in the previous
objcopy?
No reason. I see you've already committed that change.
Thanks!
--
Cheers,
Pedro Alves
On Thu, Nov 08, 2007 at 12:03:59AM +, Pedro Alves wrote:
> Christopher Faylor wrote:
>
>> That would be fine with me. OTOH, if the dllfixdbg isn't doing the
>> right thing for gdb couldn't it be adapted to include the required
>> sections?
>
> Yep. Here is a patch that does that.
>
> Testsuit
On Nov 8 00:03, Pedro Alves wrote:
> Christopher Faylor wrote:
>
>> That would be fine with me. OTOH, if the dllfixdbg isn't doing the
>> right thing for gdb couldn't it be adapted to include the required
>> sections?
>
> Yep. Here is a patch that does that.
>
> Testsuite shows no changes, I cou
Christopher Faylor wrote:
That would be fine with me. OTOH, if the dllfixdbg isn't doing the
right thing for gdb couldn't it be adapted to include the required
sections?
Yep. Here is a patch that does that.
Testsuite shows no changes, I could build cygwin in cygwin with
this, and gdb doesn
Christopher Faylor wrote:
On Mon, Nov 05, 2007 at 12:20:48PM +0100, Corinna Vinschen wrote:
On Nov 5 10:19, Pedro Alves wrote:
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 head
On Nov 5 06:57, Christopher Faylor wrote:
> On Mon, Nov 05, 2007 at 12:20:48PM +0100, Corinna Vinschen wrote:
> >On Nov 5 10:19, Pedro Alves wrote:
> >> It occurred me that the problem may be that
> >> ld is accounting for the virtual address and virtual size of the last
> >> section
> >> to wri
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 ...
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
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
On Nov 4 04:00, Pedro Alves wrote:
> 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 wor
On Sun, Nov 04, 2007 at 12:48:38AM -0700, Brian Dessent wrote:
>Pedro Alves wrote:
>
>> 10 .cygheap 000a 611e 611e 2**2
>> ALLOC
>> 11 .gnu_debuglink 0010 6128 6128 001d0a00 2**2
>> CONTENTS, READONLY, DEBUGGING
>>
>
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
17 matches
Mail list logo
