Notice: We have migrated to GitLab launching 2024-05-01 see here:

#2473 assigned defect

mvme162 has invalid code in start up

Reported by: Eric Williams Owned by: Needs Funding
Priority: high Milestone: Indefinite
Component: bsps Version: 4.11
Severity: blocker Keywords: bsp m68k
Cc: Blocked By:


TRAP #7 generated in code for bsp_start(). This is same issue as ticket #2204, fix needs to be extended to all m68k BSPs.

Change History (6)

comment:1 Changed on 11/18/15 at 22:54:59 by Chris Johns

Thanks Eric.

Is this important for 4.11?

comment:2 Changed on 11/19/15 at 00:14:48 by Joel Sherrill

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.

Given this was the response on #2204. Should this option be swept into all m68k BSPs? Or should it be added in a place (not sure offhand of the spot) where it will apply to all targets and BSPs?

I am prone to say we need to do this for 4.11. It likely breaks every BSP on any architecture which touches memory at 0.

comment:3 Changed on 11/19/15 at 01:02:10 by Chris Johns

I did not add the option and fixed the BSP as per the commit that closes the ticket. I suggest we fix the m68k BSPs.

comment:4 Changed on 11/19/15 at 15:18:39 by Joel Sherrill

OK. Is there any easy way to identify the BSPs impacted? It would be nice to have a master list to work through.

comment:5 Changed on 01/26/17 at 07:16:00 by Sebastian Huber


comment:6 Changed on 02/15/17 at 13:37:51 by Sebastian Huber

Milestone: 4.11.2Indefinite
Owner: changed from Chris Johns to Needs Funding
Status: newassigned
Note: See TracTickets for help on using tickets.