Memory View of Labeled Variables

[lpcware]

Content originally posted in LPCWare by cwpjr on Fri Feb 01 17:19:48 MST 2013
Variables in my .bss section have labels like
ABASE:  .word 1
NBASE:  .word 1

While debugging I want to see the variable or regions of memory allocated in the .bss. I also need to type ascii into some regions.
When I attempt to enter the label name NBASE or NBASE: in the memory view and it always opens a memory view at 0x000.

The memory view help says I can enter a hex address yet nowhere in the debug viewpoints are the labels address values shown. Besides entering labels to see it's value is a standard debug function so I expect this can be done. The rest of the help refers to C expressions while this is an assembly program.

Thanks in advance. Clyde

[lpcware]

Content originally posted in LPCWare by wrighflyer on Sun Feb 03 10:54:26 MST 2013
If I ever have a question about GNU [B]as[/B] syntax I just write what I want to achieve in the simplest C possible then compile with -save-temps and study the .s file.

[lpcware]

Content originally posted in LPCWare by Rob65 on Sun Feb 03 06:48:52 MST 2013
Nice to see some assembly knowledge being shared here

Let me try to share something about the different segments in memory.
I'm using snippets of the adc_buzzer example from examples.lpc17xx.new.zip but this is be similar for other targets.

The LPCXpresso tools create a project with and [B]adc_buzzerer_adc_Debug_mem.ld[/B] describing the memory layout. In this file the memory layout is defined. MFlash512 is the Flash memory and RamLoc32 is the first 32k RAM bank.
adc_buzzerer_adc_Debug.ld is the main linker file, describing which sections of your program go to which sections in memory and where these sections are located.

Let me just take a snippet of that file:

SECTIONS
{
    [COLOR=Red].text [/COLOR]:
    {
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)

    } [COLOR=Red]> MFlash512[/COLOR]

...
    _etext = .;
        
   [COLOR=Red] .data[/COLOR] :
    {
        _data = .;
        *(vtable)
        *(.data*)
        _edata = .;
    } [COLOR=Red]> RamLoc32 AT>MFlash512[/COLOR]

    /* zero initialized data */
   [COLOR=Red] .bss[/COLOR] :
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        _ebss = .;
    } [COLOR=Red]> RamLoc32[/COLOR]

I have just taken .text, .data and the .bss sections but there are some more.
.text contains the "text" being program code, .data is initialized data and .bss is the uninitialized static data.
Uninitialized ... meaning that most system will write all zeros to this section but this does not have to be the case. I know some embedded systems where you should not assume this.

At the end of each section there is a ">" sign followed by the name of a memory region. As you can see, .text goes into the Flash and .bss into RAM.
The .data section is different. Your program locates this in RAM but the .axf file puts this in Flash (using the >AT in the linker file). This is because this is pre-initialized data.
The startup code (in ResetISR) copied the pre-initialized content found in Flash into the RAM region that is assigned to this section using the following code:

ResetISR(void) {
    unsigned long *pulSrc, *pulDest;

    //
    // Copy the data segment initializers from flash to SRAM.
    //
    pulsrc=&_etext;
    for(pulDest = &_data; pulDest < &_edata; )
    {
        *pulDest++ = *pulSrc++;
    }

This copied all content of the .data section (ranging from _etext to _edata) from Flash into RAM to make sure that your initialized static data has the correct values.

Then the startup code continues with:

    //
    // Zero fill the bss segment.  This is done with inline assembly since this
    // will clear the value of pulDest if it is not kept in a register.
    //
    __asm("    ldr     r0, =_bss\n"
          "    ldr     r1, =_ebss\n"
          "    mov     r2, #0\n"
          "    .thumb_func\n"
          "zero_loop:\n"
          "        cmp     r0, r1\n"
          "        it      lt\n"
          "        strlt   r2, [r0], #4\n"
          "        blt     zero_loop");

Clearing the content of the .bss section.

The assembler does not know anything about these section names, it's all just in our minds (and the program)...
So if you place a .word into the .bss section, the assembler will just create a word in the .bss section. The debugger will happily program the flash, write any data into RAM and then start executing your program.

So it is most likely that your .bss section is cleared.
Even if it is not being cleared, is is just bad habit to place initialized data into your .bss section. Also it will not be re-initialized when you restart your program.

Regards,

Rob

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sat Feb 02 17:11:21 MST 2013
[FONT=Tahoma][SIZE=2]Clyde, I accept you statement about the use of .word, etc. in bss sections
I have no time to setup a test case and no reason to doubt what you say.

However, I suggest that this is bad practice as a casual glance at such source
files can easily be missunderstood as per my original comment.

The consistent use of '.space xxx' is, to my way of thinking, self documenting and
should never cause confusion on quick scanning of your source files.
Personally, I would rewrite your example as this:

[/SIZE][/FONT][FONT=Tahoma][SIZE=2].bss
ABASE:
NBASE:  .space 4     ; one uninitialised word allocated, both labels have the same address
[/SIZE][/FONT][FONT=Tahoma][SIZE=2]
Cheers, Mike
[/SIZE][/FONT][FONT=Tahoma][SIZE=2]
[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sat Feb 02 16:31:10 MST 2013

---

Quote: cwpjr
[FONT=Tahoma][SIZE=2]
Also the .bss is initialized to all zeroes on load, at least in version 5.
[/SIZE][/FONT]

---

[FONT=Tahoma][SIZE=2]
[/SIZE][/FONT] [FONT=Tahoma][SIZE=2]
There is nothing magic about '.bss'; it is only zeros if code (either a run time setup library or your own code if you take immediate control at reset) actually clears it.

It might retain zeros after a reset without removing power from the chip, and it is possible that some debuggers themselves clears that region of memory. This will not be the case when code runs from the flash without any debugger involvement.

After power has been removed and re-applied to the chip, all non-volatile memory is random until somebody somewhere writes zeros to it.

The LPC-Link part of a LPCXpresso board will keep the board powered until you unplug the USB connector for instance.

Some chips allow for external memory; one can position bss there  too.

My own startup routines have code to zero bss; and I do see random bytes (after power removal) as I debug that very code.

Mike

[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by cwpjr on Sat Feb 02 14:48:47 MST 2013
About this comment:
[FONT=Tahoma][SIZE=2]in BSS ([I]uninitialised[/I] space) you must not declare [I]data[/I]; you must only [I]reserve[/I] space

XXX: .word 1 (4 bytes initialised to 0x00000001) [WRONG] Only allowed in '.data'
XXX: .space 4 (4 bytes -- 1 word -- reserved, contents are unpredicatable until
       your code writes to it.

This a very common misunderstanding and leads to subtle bugs.

E.g. with .word 20 you expect to have 80 bytes (20 words) but you get 4 bytes
(1 word) that happens to hold the [I]value[/I] 20 decimal.
That's a very different thing!

[SIZE=2]:[SIZE=2]As you stated initially: [SIZE=2]in the .bss .word 1 [SIZE=2]doesn't[/SIZE] initialize the word to [SIZE=2]1, and neither will .word 20 cause an initialization or allocation of anything but a word.
[SIZE=2][SIZE=2]In the .bss section these arguments are meaningless in terms of space allocation or initialization, but if [SIZE=2]omitted[/SIZE] will not allocate any spa[SIZE=2]ce. S[SIZE=2]uch that:

[SIZE=2].bss[/SIZE]
[SIZE=2]ABASE:  .word
[SIZE=2]NBASE:  .wor[SIZE=2]d[/SIZE] [SIZE=2]0 // 1 thru anything only allocated 1 word/ 4 bytes

[SIZE=2]will only allocate a word for NBASE,  and [SIZE=2]AB[SIZE=2]ASE and NBASE are the same address[/SIZE][/SIZE][/SIZE].

[SIZE=2]Also the .bss is initialized to all zeroes on load[SIZE=2], at lea[SIZE=2]st in version 5.

[SIZE=2]Again [SIZE=2]THANK YOU for assisting [SIZE=2]us assembl[SIZE=2]y programmers.

[SIZE=2]Clyde[/SIZE]
[/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE]
[/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sat Feb 02 11:01:31 MST 2013
[FONT=Tahoma][SIZE=1]As promised in my last post, I am showing how to
display data in assembler modules.
Since this will be of interrest to many users (five?),
I am submitting as a pdf for off-line reading and
I encourage all to distribute the pdf far and wide
(as long as no charge is made and my Copyright
remains intact).

[/SIZE][/FONT][LEFT][FONT=Tahoma][SIZE=1] "How to Display Assembler[/SIZE][/FONT]
[FONT=Tahoma][SIZE=1] Data Variables Etc.[/SIZE][/FONT]
[FONT=Tahoma][SIZE=1] With LPCXpresso[/SIZE][/FONT]
[FONT=Tahoma][SIZE=1] Debugger Memory View[/SIZE][/FONT]
[FONT=Tahoma][SIZE=1] Verified with[/SIZE][/FONT]
[FONT=Tahoma][SIZE=1] Version 4.3.0 (WinXP)"[/SIZE][/FONT]
[/LEFT]
[FONT=Tahoma][SIZE=1]
First in a series of "Aardvark Notes". Maybe.

Mike

[/SIZE][/FONT]

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Sat Feb 02 05:27:55 MST 2013
[FONT=Tahoma][SIZE=2]I too have struggled with the GNU's treatment of the assembler as a second-class
citizen when it comes to debugging information. With a previous debugger,
I got nowhere (and no useful help from the author).

As I too write a lot of the CPU/Base board support libraries in assembler, your post
caused me to re-examine the issue.

This time, with LPCXpresso 4.3.0 (on WinXP) I have had some success:D

Give me time to double check my facts, and list the various types of memory
that we might want to view, and I'll post my results. Probably this evening
(UK time).

[I have a visitor comming, and must leave the PC for a while;)].

Mike.

BTW, Quick observation:

in BSS ([I]uninitialised[/I] space) you must not declare [I]data[/I]; you must only [I]reserve[/I] space

XXX: .word 1 (4 bytes initialised to 0x00000001) [WRONG] Only allowed in '.data'
XXX: .space 4 (4 bytes -- 1 word -- reserved, contents are unpredicatable until
       your code writes to it.

This a very common misunderstanding and leads to subtle bugs.

E.g. with .word 20 you expect to have 80 bytes (20 words) but you get 4 bytes
(1 word) that happens to hold the [I]value[/I] 20 decimal.
That's a very different thing!

[/SIZE][/FONT]