I think I understand what is going on with this and I think there is a bug in
the linker. I will try to create a small example program with this problem to
submit when I get a chance but will describe it here.
In the file fixture_wall_switch.c there is a function that declares a local
static unit8_t. The linker reserves space for this in bss. That is why there is
a one byte allocation for the file as shown below with no associated symbol.
__bss_size includes this bytes. However, the PROVIDE for __bss_start happens
after the value of . is incremented for the local static variable in the file.
This causes the byte after the .bss section to get incorrectly zeroed.
The .bss section from the map file is below.
Bob.
.bss 0x0000029e 0x11c load address 0x0000dec4
0x0000029e PROVIDE (__bss_start, .)
*(.bss .bss.*)
.bss 0x0000029e 0x0
/usr/local/lib/gcc/msp430/4.6.3/crt0ivtbl16.o
.bss 0x0000029e 0x0 src/cmd_proc.o
.bss 0x0000029e 0x0 src/diagnostics.o
.bss 0x0000029e 0x0 src/direct_input_handler.o
.bss 0x0000029e 0x0 src/escape_seq.o
.bss 0x0000029e 0x1 src/fixture_wall_switch.o
.bss 0x0000029f 0x0 src/i2c.o
.bss 0x0000029f 0x0 src/isr-common.o
.bss 0x0000029f 0x0 src/isr-g2.o
.bss 0x0000029f 0x0 src/powercoms.o
.bss 0x0000029f 0x0 src/rx_frame_fsm.o
.bss 0x0000029f 0x0 src/tx_frame_fsm.o
.bss 0x0000029f 0x0 src/utils.o
.bss 0x0000029f 0x0 src/SingleChannel.o
.bss 0x0000029f 0x0 src/NonOffModeDevice.o
.bss 0x0000029f 0x0 src/noMotion.o
.bss 0x0000029f 0x0 src/SceneController.o
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libgcc.a(_mulqi3.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(_reset_vector__.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(__watchdog_support.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(__init_stack.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(__low_level_init.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(_copy_data.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(_clear_bss.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(__stop_progExec__.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(_endless_loop__.o)
.bss 0x0000029f 0x0
/usr/local/lib/gcc/msp430/4.6.3/libcrt0.a(_unexpected_.o)
*(COMMON)
*fill* 0x0000029f 0x1 00
COMMON 0x000002a0 0x5 src/cmd_proc.o
0x000002a0 gCmdProcTxMaxRetry
0x000002a2 gCmdProcFixtureDiscRateLimit
0x000002a4 gCmdProcReplyMsgBuffer
*fill* 0x000002a5 0x1 00
COMMON 0x000002a6 0x16 src/diagnostics.o
0x000002a6 gDiagnosticsReplyMsgBuffer
0x000002a8 gDiagnosticsDispatchActive
0x000002aa gSlaDiagsCrcFsm
0x000002b4 gSlaDiagsI2cFsm
COMMON 0x000002bc 0xd src/escape_seq.o
0x000002bc gEscapeWordTxBuffer
0x000002c2 gEscSeqIntAckBitList
0x000002c4 gEscSeqIntAckBitListII
0x000002c6 gEmptyIndex
0x000002c7 gCurrentWordIndex
0x000002c8 gTxBufferEmpty
*fill* 0x000002c9 0x1 00
COMMON 0x000002ca 0x4 src/isr-common.o
0x000002ca gSecondsCounter
0x000002cc gJiffiesCounter
COMMON 0x000002ce 0x40 src/powercoms.o
0x000002ce gBoardVer
0x000002d0 gTaskBitList
0x000002d2 gSlaCommsMode
0x000002da gBoardId
0x000002dc gSlaRxWordComms
0x000002e4 gSlaCommsCal
0x000002f8 gTimers
0x00000304 gSlaTxWordComms
COMMON 0x0000030e 0x1c src/rx_frame_fsm.o
0x0000030e gWordTimeoutFlag
0x00000310 gRxFrameStateDispatchError
0x00000312 gRxFrameEventDispatchError
0x00000314 gSlaRxFrame
COMMON 0x0000032a 0x58 src/tx_frame_fsm.o
0x0000032a gTxFrameStateDispatchError
0x0000032c gTxFrameEventDispatchError
0x0000032e gSlaTxFrame
0x0000033a gTxFrameFsmBusy
0x0000033c gTxReplyMsgBuffer
0x0000033e wc
0x00000340 gSlaTxMsgBuffer
COMMON 0x00000382 0x37 src/SceneController.o
0x00000382 gHybridPid
0x00000384 gSystemHealthAlert
0x00000385 gFluorescentFixture
0x00000386 gSwitch
0x000003a6 escapeWordTimers
0x000003b8 gSystemHealthMonitor
0x000003ba . = ALIGN (0x2)
*fill* 0x000003b9 0x1 00
0x000003ba PROVIDE (__bss_end, .)
0x0000011c PROVIDE (__bss_size, SIZEOF (.bss))
On Feb 21, 2013, at 1:29 PM, Peter Bigot <big...@acm.org> wrote:
> In the standard linker script __bss_start gets the value of . at the start of
> .bss, which immediately follows .data. .data ends with a 2-byte alignment
> instruction. I don't see how __bss_start would end up at an odd address in
> that situation.
>
> Peter
>
> On Thu, Feb 21, 2013 at 1:56 PM, Robert Henig <rhe...@redwoodsys.com> wrote:
> It looks like the bss init loop is starting one byte ahead of where it
> should. I suspect the problem is from the "src/fixture_wall_switch.o" entry
> in the map file shown below.
>
> .bss 0x0000029e 0x0 src/escape_seq.o
> .bss 0x0000029e 0x1 src/fixture_wall_switch.o
> .bss 0x0000029f 0x0 src/i2c.o
>
> Later I get:
>
> 0x0000029f PROVIDE (__bss_start, .)
>
> But __bss_start should be 0x0000029e.
>
> The net result is that the first byte in .data is zero instead of its correct
> initialized value.
>
> I confirmed that __bss_start is 0x029f and __bss_size is correct in the
> debugger.
>
> Why would "src/fixture_wall_switch.o" be allocated one byte but not show any
> symbol for that allocation?
>
> Any help? I can provide more details but I think this is the crux of the
> situation.
>
> Thanks,
> Bob.
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
