For ARM, same symbols in library meant for different archs?

Hi guys,

I just posted this in a while ago, but google reveals this is where I should have posted on a first instace!

Basically, I compiled a chain for arm-elf last week (bleeding edge versions of all), been writing some code for it, and I'm now wondering if the following could be possible:

Say I want function `foo' to be accessible at link-time for both, armv6 and armv7, being both in the same library.

For this I would write two different functions which I guess would get in depending on what is being defined due to the `-mcpu' command-line option, either `__ARM_ARCH_6M__' or `__ARM_ARCH_7M__' in this case.

Skiming through the docs, it seems I could use the attribute `ifunc ("resolver")', or also the `target' attribute.

But I guess both of them require specific support for each target arch, which seems not to be the case for ARM's as I get something along the lines of "this is not supported on this machine".

Is there anyway this can be done in a "proffesional" way, yet having same name for both versions of the functions?



Reply to
Loading thread data ...

Not really.

Why the insistence on a single library? What do you want that for?

GCC has a dedicated facility for this kind of work, called 'multilib'. It basically means you have _separate_ libs for different (sub)targets, installed in different directories, and GCC will automatically pick one of those libs based on the selected target.

No. Macros don't (directly) influence library selection, nor selection of functions from libraries.

Reply to
Hans-Bernhard Bröker

Hi Hans,

Thanks, I'll look into the multilib thing, didn't even know it existed you see.

What I'm after is of a cmsis library I can use for cortex-m3 and cortex-m0 (or even cortex-m4 in a future) as the only difference among them would be (structures, which grow with version number, and code for each function). Besides of this, the api is almost the same.

How do you guys go arround this?

What I thougth first was to have a library for each subtarget, perhaps even sharing a common header file (ifdef'ed as needed). It's just that I happened to think if a cleaner solution would be available at this time.


Reply to

As a previous poster wrote. Why? I would not attempt it at all. Keeping separate libraries for different ARM cores is the simplest method. Remember the KISS principle?

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.