FreeMASTER is unable to parse the ELF file generated using aarch64 gnu-g++

[dps]

I am trying to use FreeMaster(v3.2) as debugging tool with NXP imx 8 MP with TCP.

FreeMaster fails to parse the generated binary .I use gdwarf-4 and static linkage. 

I am using gnu cross-compiling application for ARM architectures from a Windows host using MinGW.

This is the output of file command on the binary file : 
ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, with debug_info, not stripped. 

I have tried checking if the ELF file is actually a valid ELF file by doing the following:

• Verified ELF sections with readelf -S and readelf --debug-dump
• Checked that DWARF info is present by checking .debug_info and .debug_* sections.
• Verified symbols with nm (lists symbols from object files)
  
  So my questions are:
• Can the FreeMaster use a 64 bit ELF file generated using gcc-gnu ?
• How can I debug more to understand what is the issue in parsing ?

[MichalH]

Hello,

so far FreeMASTER has been targeting MCU applications running on CortexM and other 32-bit platforms.  FreeMASTER tool does not support 64 bit variable addresses - although the communication protocol does, the limitation is in the PC tool itself. This is also a reason why parsing aarch64 ELF files fails. 

I'm sorry I do not have more optimistic answer for now.

Regards,
Michal

[dps]

Thank you for your response and for confirming my suspicions. I have a couple of follow-up questions:
If I develop a custom ELF file parser, will it be compatible with FreeMASTER?
If it isn’t currently supported, can we anticipate this feature in future releases?

[MichalH]

Hello,

you can take a look at FreeMASTER examples which use "TSA" feature. With this you do not even need to parse ELF. You can define TSA tables directly in the application and build list of variables and other symbolic information that the FreeMASTER can read and use instead of ELF. Using TSA also enables to turn on runtime memory protection (FMSTR_USE_TSA_SAFETY) which will prevent FreeMASTER to access other variables and memory. Well, also the TSA has not been tested with aarch64 compiler, but if your variables are located in lower 32bit area, it should work.

To your question: if you dump your variable sizes and addresses to a text file, FreeMASTER may read them using regular-expression based parser. In the MAP Files tab, select "File format" and "Define new regular expression-based parser":

But still, the limitation exists that the variable address must be 32 bit value only.

Support of aarch64 ELF and 64-bit variable addresses is in our backlog for next versions already, but I would not expect this to happen sooner than Q3/2025.

Regards,
Michal

[dps]

Thank you for proposing these workarounds, but I believe I’ll wait for the official release of FreeMaster with support for 64-bit variable addresses. I’d be more than happy to assist with testing it in our application when it’s available. In the meantime, I’ve already replaced the freemaster_net_lwip_tcp.c implementation with a standard Linux socket implementation, and FreeMaster is successfully connecting to the host.