#2204 closed defect (fixed)
mcf5235 has invalid code in start up
Reported by: | Chris Johns | Owned by: | Chris Johns |
---|---|---|---|
Priority: | highest | Milestone: | 4.11 |
Component: | bsps | Version: | 4.11 |
Severity: | blocker | Keywords: | bsp coldfire |
Cc: | Blocked By: | ||
Blocking: |
Description
The mcf5235 crashes on boot with:
dBUG> TRAP #7
PC: 000442F2 SR: 2704 [t.Sm.111...xnZvc]
An: 40000000 00006372 FBF7B9E5 F75F5FF7 00006286 F6F5FBFF 00006276 00006272
Dn: 001F1980 00000000 00000019 B75FFEFC FFFFFDCF FFB7AF5F DE5F5FC7 D9BBFDFE
000442F2: 0000 DC.W 0x0000
Inspection of the code with objdump shows Init5235 code is:
000442b8 <Init5235>:
442b8: 598f subql #4,%sp
442ba: 303c 3fff movew #16383,%d0
442be: 4297 clrl %sp@
442c0: 33c0 4010 0048 movew %d0,40100048 <IPSBAR+0x100048>
442c6: 70e1 moveq #-31,%d0
442c8: 13c0 4010 0040 moveb %d0,40100040 <IPSBAR+0x100040>
442ce: 70e0 moveq #-32,%d0
442d0: 33c0 4000 0080 movew %d0,40000080 <IPSBAR+0x80>
442d6: 203c 001f 0001 movel #2031617,%d0
442dc: 23c0 4000 0084 movel %d0,40000084 <IPSBAR+0x84>
442e2: 303c 1980 movew #6528,%d0
442e6: 33c0 4000 008a movew %d0,4000008a <IPSBAR+0x8a>
442ec: 42b8 0000 clrl 0 <HeapSize?>
442f0: 4e47 trap #7
...
which is wrong. It looks like something in the compiler has changes and it could the RTEMS 'm68k_set_vbr'. The .i file shows this as:
do { asm volatile ( "movec %0,%%vbr " : : "r" (0)); _VBR = (void *)0; } while(0);
and that is generating a .s of:
clr.l 0.w
trap #7
which is wrong. It is not clear what has change and what has broken with this BSP or it is the tools that are broken.
Attachments (2)
Change History (6)
Changed on 12/01/14 at 02:52:53 by Chris Johns
Attachment: | init5235.i added |
---|
Changed on 12/01/14 at 02:53:12 by Chris Johns
Attachment: | init5235.s added |
---|
Invalid assembler output.
comment:1 Changed on 12/01/14 at 03:25:10 by Chris Johns
It looks to me like a gcc bug. Moving the copy out of init5235.c generates clean code and RTEMS boots.
comment:2 Changed on 12/01/14 at 03:35:21 by Chris Johns
comment:3 Changed on 12/01/14 at 03:57:07 by Chris Johns <chrisj@…>
Owner: | set to Chris Johns <chrisj@…> |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:4 Changed on 12/01/14 at 04:06:12 by Chris Johns
The very prompt response from the gcc community is this is expected behaviour when writing to 0 on the target. The -fno-delete-null-pointer-checks option disables the check.
I am happy to have our code built with this option because we should not be writing to 0 unless it is a special case such as setting up the vector table.
I am now wondering about the state of our other BSPs.
Preprocessed source