Just to close this out:
Linker scripts comprise multiple components which must follow a specific
order so that the information is correct. Among those is that a section
declaration must appear between the markers that define its start and end.
If you mis-use memory.x to rearrange existing sections without
understanding how the base script works any resulting failures are not the
fault of the toolchain.
Peter
On Fri, Feb 22, 2013 at 1:16 PM, Robert Henig <rhe...@redwoodsys.com> wrote:
> 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
