EmbDev.net

Forum: ARM programming with GCC/GNU tools What does this mean in .map file?


von jrmymllr j. (jrmymllr)


Rate this post
useful
not useful
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.

von 900ss (900ss)


Rate this post
useful
not useful
Hi Jerry,
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 ;-)

von jrmymllr j. (jrmymllr)


Rate this post
useful
not useful
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*)

von 900ss (900ss)


Rate this post
useful
not useful
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.

von Clifford S. (clifford)


Rate this post
useful
not useful
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.

von jrmymllr j. (jrmymllr)


Attached files:

Rate this post
useful
not useful
Attached is the .map and linker file.

von jrmymllr j. (jrmymllr)


Rate this post
useful
not useful
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

von Clifford S. (clifford)


Rate this post
useful
not useful
Jerry Milner wrote:
> Attached is the .map and linker file.

I think change:

.bss :

to

.bss (NOLOAD) :

in the linker script.


Clifford

von jrmymllr j. (jrmymllr)


Rate this post
useful
not useful
Thank you, that fixed it.  I haven't tried running the binary yet but I 
believe it was strictly a linker problem.

von 900ss (Guest)


Rate this post
useful
not useful
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 
you.

von jrmymllr j. (jrmymllr)


Rate this post
useful
not useful
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.

von 900ss (Guest)


Rate this post
useful
not useful
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.

von Clifford S. (clifford)


Rate this post
useful
not useful
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.

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.