instrument function fails relocation records

[jmi]

Hello,
we try to instrument functions (single ones or all) to record their time, but it fails:

System.Exception: Could not instrument any functions. Please ensure that C:\Folder\File contains relocation records.
bei pz..ctor(String a, InstrumentationSettings c, b b, EmbeddedRTOSProfile d)
bei uo1.w1()
bei uo1.m1_2(DebugCustomizationSettings a)
bei ui1.c1()
bei VisualGDB.GDBDebugEngine.n(bp a, x2 b)

Visual Studio builds our project with the correct flag “-Wl,-q” to generate relocation records:

c:\sysgcc\arm-eabi\bin\arm-eabi-g++.exe -o ../VisualGDB/Debug/File -Wl,-gc-sections -Tscript.lds -Wl,-verbose -Wl,-q --specs=nosys.specs -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mcpu=cortex-m4 -Wl,--start-group VisualGDB/ ...

Checks with arm-eabi-objdump.exe -r Binary show relocation information as well.

We are using VisualGDB 5.3 RC1.

What can we try next? Thanks!

[support]

Hi,

v5.3RC1 is quite old. Please try updating to VisualGDB 5.4R5. If the problem persists, please check the messages in View->Other Windows->VisualGDB Diagnostics Console produced while trying to instrument the file and let us know if you find anything suspicious. If not, please consider sending the ELF file to our support email and we will try to see why VisualGDB cannot handle it properly.

[jmi]

Hi,

thanks for the hint with the VisualGDB Diagnostics Console! The error persists after updating to 5.4R5.

We figured out that it tries to place the instrumented function stubs after the latest block in our linking script. However, we use the end of our flash to save some special data. Therefore, it fails by placing the stubs outside of the flash borders without notifying.

We have a lot of free space at the flash in-between. Is it possible to choose the place for the stubs? Or do we have to clean up the end of the flash?

Best regards

• This reply was modified 5 years ago by jmi.

[support]

Yes, please try setting the explicit end of FLASH memory on the Dynamic Analysis page to the address just before the special data block you have in the FLASH. VisualGDB will then treat this special block as it it was placed in a different memory and will place the stubs after the last section in the rest of the FLASH memory.

If it doesn’t work please feel free to share the diagnostic log and we will help you find the right settings.

[jmi]

We tried you hint but without success. It seems that the settings for explicit end of FLASH are ignored. Debug log:

Launching C:\...\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 64584" -c "telnet_port 64585" -f interface/stlink-v2.cfg -c "transport select hla_swd" -f C:/.../tmpC04A.tmp -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"...
Looking for the region in FLASH to place function stubs...
The last section before 0x08100000 is .crc.
Will place instrumented function stubs at 0x08100000.
Built 0 function stubs. Total size: 0 KB
Unexpected exception: Could not instrument any functions. Please ensure that BinaryFile contains relocation records.

I attached a screenshot of the profiler gui with the correct addresses. Our linker script:

/* Generated by LinkerScriptGenerator [http://visualgdb.com/tools/LinkerScriptGenerator]
* Target: STM32F417IG
* The file is provided under the BSD license.
*/

ENTRY(Reset_Handler)

MEMORY
{
FLASH (RX) : ORIGIN = 0x0800C000, LENGTH = 1M - 48K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 128K
CCMRAM (RWX) : ORIGIN = 0x10000000, LENGTH = 64K
}

_estack = 0x10010000;

SECTIONS
{
.isr_vector :
{
PROVIDE(_interrupt_vector_ = .);
. = ALIGN(4);
KEEP(*(.isr_vector))
KEEP(*(SORT(.version_information)))
FILL(0xFF);
. = 0x200;
} > FLASH

.text :
{
. = ALIGN(4);
_stext = .;

*(.text)
*(.text*)
*(.rodata)
*(.rodata*)
*(.glue_7)
*(.glue_7t)
KEEP(*(.init))
. = ALIGN(4);
_etext = .;

} > FLASH

.ARM.extab :
{
. = ALIGN(4);
*(.ARM.extab)
*(.gnu.linkonce.armextab.*)
. = ALIGN(4);
} > FLASH

.exidx :
{
. = ALIGN(4);
PROVIDE(__exidx_start = .);
*(.ARM.exidx*)
. = ALIGN(4);
PROVIDE(__exidx_end = .);
} > FLASH

.ARM.attributes :
{
*(.ARM.attributes)
} > FLASH

.preinit_array :
{
PROVIDE(__preinit_array_start = .);
KEEP(*(.preinit_array*))
PROVIDE(__preinit_array_end = .);
} > FLASH

.init_array :
{
PROVIDE(__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array*))
PROVIDE(__init_array_end = .);
} > FLASH

. = ALIGN(4);
_sidata = .;

.data : AT(_sidata)
{
. = ALIGN(4);
_sdata = .;

PROVIDE(__data_start__ = _sdata);
*(.data)
*(.data*)
. = ALIGN(4);
_edata = .;

PROVIDE(__data_end__ = _edata);
} > SRAM

.bss :
{
. = ALIGN(4);
_sbss = .;

PROVIDE(__bss_start__ = _sbss);
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .;

PROVIDE(__bss_end__ = _ebss);
} > SRAM

.ccmram (NOLOAD):
{
. = ALIGN(4);
KEEP(*(.ccmram*))
. = ALIGN(4);
} > CCMRAM

.heap (NOLOAD) :
{
. = ALIGN(4);
PROVIDE(__heap_start__ = .);
KEEP(*(.heap))
. = ALIGN(4);
PROVIDE(__heap_end__ = .);
} > SRAM

PROVIDE(end = .);

.reserved_for_stack (NOLOAD) :
{
. = ALIGN(4);
PROVIDE(__reserved_for_stack_start__ = .);
KEEP(*(.reserved_for_stack))
. = ALIGN(4);
PROVIDE(__reserved_for_stack_end__ = .);
} > CCMRAM

.crc 0x080FFFFC:
{
LONG(0xDEADDEAD)
} > FLASH
}

 

• This reply was modified 5 years ago by jmi.

Attachments:

You must be logged in to view attached files.

[support]

Thanks for the update. We have rechecked the logic responsible for finding the end of FLASH/RAM and it turned that a recent refactoring on our side broke the scenario you are trying to use.

We have fixed it in this build: VisualGDB-5.4.105.3142.msi

[Author]

Posts