Using VisualGDB with standalone code

Sysprogs forums Forums VisualGDB Using VisualGDB with standalone code

This topic contains 6 replies, has 2 voices, and was last updated by  support 1 month, 1 week ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #28664

    R2COM
    Participant

    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?

     

     

    #28665

    R2COM
    Participant

    here is another visual snapshot to the problem:

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

    so any ideas?

    #28666

    R2COM
    Participant

    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?

    #28671

    R2COM
    Participant

    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?

    #28677

    R2COM
    Participant

    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 1 month, 1 week ago by  R2COM.
    #28681

    R2COM
    Participant

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

    #28683

    support
    Keymaster

    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.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.