Using VisualGDB with standalone code

[R2COM]

I am trying to provide all minimum necessary files on my own for compilation and debugging. No HAL, no CMSIS legacy stuff. Nothing, just my own linker script, interrupt handlers, startup file and main.cpp.

After putting it alltogether and selecting a project without HAL and running i see following error :

Severity Description Project File Line
Error undefined reference to `__bss_start__’ baremetal5 E:\projects\DEV\stm32\baremetal5\(.text+0x70) 0

the thing is, i do not have “__bss_start__” i do have “__bss_start” and that is nicely defined in linker script and handled properly in startup code.

and if you look closely it is strange addition of the (.text+0x70) to the textline indicated in the error. seems like some path is broken but i do not know why.

 

basically, what i do is i create a simple project, select my device, select build tool (MSBuild or GNU – didnt make difference, all had same result); then i remove the BSP support (because as i said i provide all needed minimum files myself), then i remove stuff like semihosting, no HAL etc obviously. and that is it. project created.

project seems to compile without mistake as well, but what you see happens at the linking stage.

what part of VisualGDB and basic toolchain failed here? where should i look at?

 

 

[R2COM]

here is another visual snapshot to the problem:

https://i.imgur.com/UxMR6lQ.jpg

so any ideas?

[R2COM]

i noticed that i can remove these errors by changing the name of sections inside my linker & startup from “__bss_start” to “__bss_start__” same thing with end macro.

can someone explain why it solves problem?

[R2COM]

so can i get an explanation from support team? what is happening under the hood what prevents me using custom names of memory sections?

 

why using “__bss_start” label together with my startup code was problematic and lead to problems described in first post but usage of name like “__bss_start__” is totally fine?

[R2COM]

i will put example here again, for example here is a linkers script i have (some portion of it):

SECTIONS {
__stacktop = ORIGIN(SRAM) + LENGTH(SRAM);
__data_load = LOADADDR(.data);
. = ORIGIN(SRAM);

.data ALIGN(4) : {
__data_start = .;
*(.data)
*(.data*)
. = ALIGN(4);
__data_end = .;
} >SRAM AT >FLASH

.bss ALIGN(4) (NOLOAD) : {
__bss_start = .;
/* PROVIDE(__bss_start__ = __bss_start); */
*(.bss)
*(.bss*)
. = ALIGN(4);
__bss_end = .;
PROVIDE(__bss_end__ = __bss_end);
*(.noinit)
*(.noinit*)
} >SRAM

. = ALIGN(4);
__heap_start = .;
}

 

do you see the commented out line in bold? so if this line is commented out – it causes the error which i talked about in first post.

but if that line is there, then all works. my question: WHY?

the startup code inside my .cpp file references __bss_start, so why is this stuff happening?

what is hidden from me?

• This reply was modified 3 years, 9 months ago by R2COM.

[R2COM]

guys seriously? can i get at least something from support team? am i not asking the legitimate question?

[support]

Please note that we usually respond to most inquiries within 24-48 hours.

Please note that VisualGDB uses the original GCC toolchain (i.e. the GNU linker) to link the projects. You can find the linker command line used by VisualGDB per our troubleshooting instructions. VisualGDB itself does not introduce any additional logic on top of what is done by the GNU linker.

Generally, we are not able to provide insights into the inner workings of the open-source tools used by VisualGDB, as they often involve very complex logic. Please consider community-driven resources like StackOverflow to get help with open-source tools.

If you are looking for a fully supported compiler, please consider using VisualGDB with IAR or Keil. This way you can still enjoy the VisualGDB features, and get compiler-specific support from IAR/Keil teams.

[Author]

Posts