This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: debug_info strangeness (arm-mingw32ce)
- From: Danny Backx <danny dot backx at scarlet dot be>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: binutils <binutils at sourceware dot org>
- Date: Wed, 02 Dec 2009 20:04:06 +0100
- Subject: Re: debug_info strangeness (arm-mingw32ce)
- References: <20091119020742.GN26333@bubble.grove.modra.org> <20091119021031.GO26333@bubble.grove.modra.org> <1258628885.5171.275.camel@pavilion> <20091119120423.GA24438@bubble.grove.modra.org> <1258652224.5171.290.camel@pavilion> <20091119211601.GB24438@bubble.grove.modra.org> <1258907946.5171.322.camel@pavilion> <1259264606.5171.363.camel@pavilion> <20091127010854.GB692@bubble.grove.modra.org> <1259418805.5171.385.camel@pavilion> <20091130101520.GD692@bubble.grove.modra.org>
- Reply-to: danny dot backx at scarlet dot be
On Mon, 2009-11-30 at 20:45 +1030, Alan Modra wrote:
> On Sat, Nov 28, 2009 at 03:33:25PM +0100, Danny Backx wrote:
> > On Fri, 2009-11-27 at 11:38 +1030, Alan Modra wrote:
> > > On Thu, Nov 26, 2009 at 08:43:26PM +0100, Danny Backx wrote:
> > > > Or is it probably what it looks like to me - an error ?
> > >
> > > Yes. I expect something is corrupting the linker's statement_list,
> > > since ld appears to be sizing output sections correctly but not
> > > writing them out. To test this hypothesis, put a break in
> > > lang_process before the lang_size_sections call, and another in
> > > ldwrite. Dump the list using dprint_statement at both points.
> >
> > Not being an expert, I don't see much difference. See below.
>
> No, my guess was wrong. The linker's statement list looks OK.
>
> > And similarly (writing Modra 1a/b) in ldlang.c . I assume that this is
> > what you requested.
>
> I wasn't requesting the dump.
I used the wrong word, should have said "meant" instead of "requested".
Anyway : in _bfd_coff_final_link (bfd/cofflink.c) around line 900 in
current binutils head, this code is present :
for (o = abfd->sections; o != NULL; o = o->next)
{
for (p = o->map_head.link_order; p != NULL; p = p->next)
{
if (p->type == bfd_indirect_link_order
&& bfd_family_coff (p->u.indirect.section->owner))
{
sub = p->u.indirect.section->owner;
if (! bfd_coff_link_output_has_begun (sub, & finfo))
{
if (! _bfd_coff_link_input_bfd (&finfo, sub))
goto error_return;
sub->output_has_begun = TRUE;
}
Not being a binutils expert, this code is not easy for me to understand.
What appears to happen is that _bfd_coff_link_input_bfd is not called
for the .debug_info section of crt3.o, because
bfd_coff_link_output_has_begun evaluates to false.
Adding these lines :
else {
if (! _bfd_coff_link_input_bfd (&finfo, sub))
goto error_return;
sub->output_has_begun = TRUE;
}
changes that, but obviously not entirely in the right way.
This code gets executed about 180 times for my simple example program.
The result is actually pretty good :
- the executable works
- gdb recognizes it
- when observed with objdump -xs, all sections appear to have the
same size and contents as before, except of course the problematic
one is right now
Drawback : too many symbols get defined (haven't looked into the detail
yet) which makes the exe file 78 KB in size, the original was 28 KB.
As I said I don't understand the detail of the code involved so e.g. I
don't understand why this if statement is there in the first place, and
as a consequence I'm not sure what the right fix is.
Does anyone have another clue for me ? Where do I look ?
Danny
Files I just uploaded to http://danny.backx.info/download/cegcc/modra :
-rw-r--r-- 1 4194472 9305 28276 Dec 2 12:01 d2-nofix.exe
-rw-r--r-- 1 4194472 9305 85862 Dec 2 12:01 d2-nofix.objdump
-rw-r--r-- 1 4194472 9305 78262 Dec 2 12:01 d2.exe
-rw-r--r-- 1 4194472 9305 240880 Dec 2 12:01 d2.objdump
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info