I will need to put some time into recreating the problem in a simple way. I see
that the map I just sent does not match the one I had before making some
changes. I'll file a ticket when I can.
Thanks,
Bob.
On Feb 22, 2013, at 10:57 AM, Peter Bigot <big...@acm.org> wrote:
> 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
