TM4C1294NCPDT: TI Clang v1.3.0LTS ELF output can't combine --absolute (-a) and --relocatable (-r)

Hi John,

I'm going to send this to our CCS team to help with some of the formatting aspects but I wanted to mention that perhaps something you may need to do as part of this process is re-compile the TivaWare libraries which we walk through how to do in Section 4.2 of our TivaWare User's Guide: https://www.ti.com/lit/pdf/spmu373

Best Regards,

Ralph Jacobi

Hi Ralph,

Sorry for apparently posting on the wrong forum, and thanks for the guidance!

John

John DeVos said:

Is there a way to get COFF output

Unfortunately, no.

John DeVos said:

is it possible to generate a BIN file that is both absolute and relocatable?

Unfortunately, no.

John DeVos said:

The set of projects in question includes an application, which is built more conventionally,  and several "drivers" which (at least with the TI v5.2.9 tools) required both the --absolute and --relocatable flags.  This allows the drivers to be loaded into FLASH at a known location at run time and (after a reboot) to be accessed by the application through a dispatch table located at the base address of the driver.

That's an unusual way to organize a program.  I can't recall ever seeing this before.  I cannot think of a way to do it with ELF object files.  ELF is the only object file format supported by tiarmclang.

Instead, consider making the code for each driver a static library.  The main application calls the functions in each driver/library like any other function call.  No dispatch table is needed.  The main application links against these libraries.  This means a delay is imposed on the decision about where the functions from the drivers/libraries go into memory.  In your old build, this decision happens when the driver is linked.  Now the decision is made when the entire application is linked.

Please let me know if this suggestion resolves the problem.

Thanks and regards,

-George

Hi George,

Thanks for the response, but I'm afraid it's no help.

The main application is never linked with the drivers.  Up to four drivers can be loaded into dedicated FLASH blocks at run time and the driver functions are accessed by the main app via pointers to the known locations of the functions that define the driver interface.  The whole point is to decouple the drivers from the main app so a) drivers can be loaded by customers without impacting the main app, and b) development of the main app and the drivers are not tied together.

Ideally, using TI v20.2.5LTS would be an option, but I believe one of the settings required (or maybe the --absolute and --relocatable combo) for the driver to build as needed was deprecated sometime after the compiler version we're still using for the drivers (TI v5.2.9) was current.

We can continue to use TI v5.2.9 for the time being, but if the current driver scheme is literally impossible with more recent tools, that will have a serious impact on the product the app and drivers implement. 

I'd very much like to get any thoughts you or others there may have on how this scheme can be accomplished with the new toolchain.  I'm happy to provide more details of the current implementation if it would help.

Thanks,

John

John DeVos said:

Up to four drivers can be loaded into dedicated FLASH blocks at run time

Exactly when does this load into FLASH occur?  After the system starts running?  

Thanks and regards,

-George

Hi George,

Driver loading can take place any time after the system completes boot up, and is managed by the main application and a dedicated Windows utility.  Once a driver is loaded it remains in Flash until replaced.

When a board is first programmed, a "base" driver is loaded into each dedicated Flash block.  The base driver implements all the required interface functions, but they just return immediately.  It's just to prevent the main app from calling a random pointer.

Thanks, and let me know if there are more questions, 

John

I do not entirely understand your system.  But some points are clear.  It is fairly sophisticated, and getting it to work with ELF object files is likely to require significant changes.

Here are some related documents.  The article A Brief History of TI Object File Formats is a good place to start understanding ELF.  For further details, please refer to the tiarmclang Compiler User Manual chapters Introduction to Object Modules and Program Loading and Running.

Thanks and regards,

-George