In the map entries you provide the bss start is word-aligned and has a
value of 0x029e, as it's supposed to have. There's that one-byte static
that's placed at 0x029e. Then there's a fill byte at 0x029f so the common
section is aligned. The length of the BSS section happens to include the
fill, so the unused byte at the end of the section is unnecessarily
zeroed. Is that what you're worried about?
I'm not seeing where there's a bug here. There's an infelicity, in that
the bss section is zeroed one byte at a time while the values for start and
size would permit it to be zeroed one word at a time, but I can't work up
much concern about that since it doesn't clobber any data.
At any rate, getting excerpts from map files without context or source
doesn't seem to be working. If you think there's a bug create a complete
and minimal reproducing test case and add it as a tracker ticket on the SF
project along with a description of exactly what you see, how you got what
you see, and why you think it's wrong. Include any custom linker scripts
you might be using.
Peter
On Fri, Feb 22, 2013 at 12:20 PM, Robert Henig <rhe...@redwoodsys.com>wrote:
> 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
