Re: Rewrite/fix cygwin1.dbg generation
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... what about teaching objcopy that when doing --add-gnu-debuglink if there'a already a section named .gnu_debuglink (and it's of sufficient length to hold the .dbg filename) that it can just rewrite its contents, rather than appending a new section? That way we can continue to allocate the section in the link script (except without having to call it .gnu_debuglink_overlay) so that we can put the .cygheap last, but we don't have to do the dllfixdbg hackery to get the ordering correct. The downside here would be that if we rely on this feature of objcopy then we'd need to either require bleeding edge binutils to build Cygwin or do some kind of autoconf runtime test to test for behavior. Still, it would be nice to lay the groundwork for being able to one day retire the hackery. Brian
Re: Rewrite/fix cygwin1.dbg generation
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 I'll come up with a different fix. Just thinking out loud here... what about teaching objcopy that when doing --add-gnu-debuglink if there'a already a section named .gnu_debuglink (and it's of sufficient length to hold the .dbg filename) that it can just rewrite its contents, rather than appending a new section? That way we can continue to allocate the section in the link script (except without having to call it .gnu_debuglink_overlay) so that we can put the .cygheap last, but we don't have to do the dllfixdbg hackery to get the ordering correct. 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? cgf
