I have this in my .map file (GCC, Cortex-M)
.bss 0x20000108 0x2c90 load address 0x00028793
0x20000108 _bss = .
FLASH starts at 0x0, and RAM starts at 0x20000000. From other parts of
the .map file, it looks like my app fills 0x0 - 0x0002868c, which makes
sense according to the size of the .bin I'm programming in. I've had
errors before from the linker when I turn off optimization and the
binary gets larger, because I reserve everything starting from 0x36000
for other data, even though I'm not seeing anything beyond the last
.rodata.
I'll try to explain...
BSS is a section which means (B)lock (S)tarted by (S)ymbol. Don't care
about the name.
In this section all static variables and static data collected which are
not initialized with data. This block needs no room in the created
binary file as it contains no data, only the length and start address
(in your case 0x20000108) is important for address calculations.
Most startup codes use the symbols (e.g. '__bss_start', '__bss_end__'),
provided by the linker and wash(x) the memory with zero at startup with
the provided addresses.
Here is also a link to WIKIPEDIA:
http://en.wikipedia.org/wiki/.bss
Hopefully you understand my explanation as I'm not a native english
speaker ;-)
900ss
(x) This word I found in the past for a function to fill memory with
zero and I like it ;-)
I understand you perfectly, but am still a little confused by this.
I'll be more specific by explaining the exact problem better:
I compiled with -o0 (no optimization), so my code got a little bigger.
It's not the way I plan on running it, but it's good for debugging. For
any new viewers of this message, I have a Cortex-M3 and using GCC.
FLASH is from 0x0 - 0x3FFFF, and SRAM is from 0x20000000 - 0x20017FFF.
I'm using __attribute__((section("scstation0"))) to place "scstation0"
starting at 0x36000. The application is filling 0x0 - 0x34dc0, based
upon (my best guess) the .map file. I also double checked by looking at
the size of the resulting .bin file if I temporarily REMOVE
"scstation0"; in this case it's 0x34EB7 in length.
So, the point is, it seems the application is getting nowhere close to
the 0x36000 where "scstation0" starts. But, when I link I see this:
c:/program files/codesourcery/sourcery g++
lite/bin/../lib/gcc/arm-none-eabi/4.3
.3/../../../../arm-none-eabi/bin/ld.exe: section scstation0 [00036000 ->
00037fc
3] overlaps section .bss [00034ec7 -> 00037b16]
collect2: ld returned 1 exit status
make: *** [RTOSDemo.axf] Error 1
So .bss claims to run all the way to 0x37B16, but my application writes
non-volatile data during run-time anyway to "scstation0" and I have no
problems. What does this actually all mean?
Please see below for part of the .map file which was generated with -o0,
which has different addresses than my initial post.
.data 0x20000100 0x8 c:/program
files/codesourcery/sourcery g++
lite/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/lib/th
umb2\libc.a(lib_a-ctype_.o)
0x20000100 __ctype_ptr
0x20000104 _ctype_ptr_
0x20000108 _edata = .
.bss 0x20000108 0x2c50 load address 0x00034ec7
0x20000108 _bss = .
*(.bss*)
Jerry Milner wrote:
> I'm using __attribute__((section("scstation0"))) to place "scstation0"
> starting at 0x36000.
Where you give the linker the information that scstation0 start at
0x36000?
> ...., but my application writes
> non-volatile data during run-time anyway to "scstation0" and I have no
> problems.
This makes me wondering, as the location is in the Flash memory. How you
wrote data in there? You have to use special flash write functions
otherwise no data is written there.
Sorry, I don't know why the secion bss overlaps with your scstation0. In
my opinion the bss don't have to reserve space in the flash rom but the
error message let us learn others!? I take a look at my map files and
the it seems to be the same.
A good idea is to post the linkerscript and also the output of your make
process. So also people looking here can see more details.
It is interesting to note that the length of [00034ec7 -> 00037b16] is
the same as the size of your BSS section.
I wonder if this is an issue with your linker script. I suggest that
you post that and probably the complete map file.
By the way, to answer 900ss I tell the linker that my data section
starts at 0x36000 by using in the makefile:
-Wl,--section-start=scstation0=0x036000
Jerry, can you please post the new mapfile? I tried the NOLOAD also a
few days ago, when you post your problem, but I saw no changes in the
mapfile in my small test project. That's the reason why I don't post
that. Now I like to know if there is a difference in your mapfile. Thank
It looks like it didn't change my mapfile, either. Here's the lines
that I believe was causing problems before:
.data 0x200000fc 0x8 c:/program
files/codesourcery/sourcery g++
lite/bin/../lib/gcc/arm-none-eabi/4.3.3/../../../../arm-none-eabi/lib/th
umb2\libc.a(lib_a-ctype_.o)
0x200000fc __ctype_ptr
0x20000100 _ctype_ptr_
0x20000104 _edata = .
.bss 0x20000104 0x3034 load address 0x00028377
0x20000104 _bss = .
The linker doesn't complain anymore though. Perhaps the NOLOAD just
tells the linker that nothing is going in that region, so it doesn't
generate an error.
Oh, to answer your question about writing to Flash memory, yes, I have
to use registers on the micro to write to Flash. Not all micros are
able to, but I believe mostly the lower end ones aren't able to.
OK, then it looks the same as in my try. I guess yo are right, it tells
the linker nothing to load, but he didn't change the map file.
And yes, for the writing to flash I was wondering a little bit.... :-)
Thank you.
900ss wrote:
> OK, then it looks the same as in my try. I guess yo are right, it tells
> the linker nothing to load, but he didn't change the map file.
Since the linker aborted in an error, it seems likely that it would not
have generated a map file, so the map file shown would have been from an
earlier successful build.
