Using the GCC ARM Embedded toolchain:
"As part of its ongoing commitment to maintaining and enhancing GCC compiler support for the ARM architecture, ARM is maintaining a GNU toolchain with a GCC source branch targeted at Embedded ARM Processors ... ARM employees are maintaining this project."
launchpad.net/.../
As Keil is also now an ARM company, is it intended that uVision should be able to debug an executable built with the GCC ARM Embedded toolchain?
At the moment, when I try, I get
load my_file.elf *** error 59: invalid absolute module
This is unhelpful, as it gives no information at all on what is "invalid" about it!
http://www.keil.com/support/docs/3692.htm says:
"The error message 'invalid absolute Module' indicates a problem with the debug information loader in µVision. Unfortunately, we can't guarantee that µVision can load .ELF-Files from all 3rd party tools."
Does the GCC ARM Embedded toolchain still count as "3rd-party"?
Is there a specific set of GCC ARM Embedded options to get debug information compatible with µVision?
Cross-post on the GCC ARM Embedded questions page:
answers.launchpad.net/.../271233
Wouldn't anything gcc always be considered 3rd party, since gcc isn't owned by any processor manufacturers or tool vendors?
I guess you could say that.
But, in the case of GCC ARM Embedded, ARM have stated a specific commitment to it.
So that might make it a "special case" wrt Keil - an ARM comany ... ?
Yes, I know it's a common practice that the chip manufacturers donates time and developers to do gcc development, to make sure that gcc gets good support for their processors. But because of gcc licensing terms, they will never get any "ownership" over their contributions.
So gcc will, and must, stay a third-party tool.
But unless ARM has decided that gdb is plenty good enough, it would be meaningful to also invest some time into improving integration support with the Keil tools. Except for the issue that gcc will not have any code size limitations, and will allow very creative linking concepts if someone wants to split code into multiple 32kB code "bundles" that can interact with each other.
Yes - that is the point of this thread!
From latest posts on the GCC ARM Embedded forum, it seems that, although "interoperability between different toolchains is generally desirable", there is no specific work being done on this