Forest through the Trees

[Mark Klein <mklein at dis dot com>]

I've got a problem that is driving me absolutely crazy and I'm
hoping the collective wisdom here can help:

I have a routine that's a global constructor that is causing 
corruption of some of cc1's structures. I'm debugging this
with a system native debugger as I've not yet been able to
complete the gdb port for this platform (and that compounds
the issue), so I've added a bunch of debug_tree() near
where I think the problem happens. Here's the pertinent output:

 <function_type 41b56ce8
    type <void_type 41b56310 void allocated from permanent_obstack
        permanent VOID
        size <integer_cst 41b562e0 constant permanent 0>
        align 8 symtab 0 alias set -1
        pointer_to_this <pointer_type 41b563f0 __builtin_va_list>>
    allocated from permanent_obstack
    permanent DI
    size <integer_cst 41b4d938 type <integer_type 41b4d8a8 unsigned int>
constan
t permanent 64>
    align 64 symtab 0 alias set -1
    pointer_to_this <pointer_type 41b589a8>>

 <function_decl 41b69928 __MPE_arm_subsystem_break
    type <function_type 41b56d58
        type <void_type 41b56310 void allocated from permanent_obstack
            permanent no-force-blk needs-constructing packed type_2 type_3
type_
4 type_6**** Illegal data address (TRAPS 65).
 
The corruption comes to the type at 0x41b56310, but notice above that
it was OK for the prior function_type node. I've set a data breakpoint
and can see the instruction causing the problem. It appears that this
is attempting to do a base relative update of a structure and the
base address is no longer correct.

I had run into similar issues with bugs in memcpy()/memmove()/bcopy()
on this platform in not being able to do ripple moves. I had suspected
the same here, but I'm pretty sure I've ruled that out. But, I can't
see where the base address is getting mucked with.

Any collective wisdom would sure be appreciated.

TIA,

Mark

--
Mark Klein                                    DIS International, Ltd.
http://www.dis.com                            415-892-8400
PGP Public Key Available
--