[gccsdk] Autobuilding Battle of Wesnoth

alan buckley alan_baa at hotmail.com
Tue Jul 15 05:42:39 PDT 2008


> On Fri, 11 Jul 2008 15:21:00 +0100 Lee Noar wrote:
>

[snip what I've tried so far]

>>
>> I believe I tried this when you suggested it previously, but can't remember
>> how I ran showregs, if I did at all. I assume the where command register
>> dump in Reporter is giving the same information.
>
> Yes, it does.
>

Thanks for confirming this for me. I've now managed with the help of Reporter
and StrongEd managed to find where the problem routine is called from.

It appears to be in code generated by the compiler for static initialisation and
destruction.

The code that is causing the jump at is:

LDR R3, &005EE8A4
MOV R14,PC
MOV PC, R3

The link register (R14) was pointing to the next address that was 005EE884

In the code image the location pointed to contains zero, but I assume this
is updated when the program is run which causes it to jump to, or just
before, &03813584 which then causes the crash.

Looking back in the code from the crash location the previous embedded
function name is _Z41__static_initialization_and_destruction_0ii.

A search for this function in the gcc source turns it up in gcc/cp/decl2.c
where (I believe) it is written into the code by the compiler.

Unfortunately I have no clue as to what this code is actually doing or
how it ends up generating the actual code for the application.

It may be this code is OK, but there is a problem with the code that
fills in the address at run time.

Can someone look at the relevant code in gcc to see what could be
happening for me?

I get identical result if I run the program as an ELF executable or
after it has been passed through elf2aif.

Thanks,
Alan

_________________________________________________________________
The John Lewis Clearance - save up to 50% with FREE delivery
http://clk.atdmt.com/UKM/go/101719806/direct/01/



More information about the gcc mailing list