$ cat mod.c int f(int a, int b) { return a % b; } unsigned int g(unsigned int a, unsigned int b) { return a % b; } $ clang -target arm-elf-eabi -S mod.c -o - | grep mod .file "mod.c" bl __modsi3 bl __umodsi3 $ clang -target arm-none-eabi -S mod.c -o - | grep mod .file "mod.c" bl __aeabi_idivmod bl __aeabi_uidivmod For conformance reasons, both should output the EABI calls.
It seems that this only happens when you chose a triple that has both ELF and EABI, since both are considered "environments". The "arm-elf-eabi" triple is normalized to "armv4t---elf-eabi", since "elf" is a valid environment, it completely ignores the EABI portion. Since I could have ELF files with any ABI in it, making ELF an environment doesn't make much sense, though I can see it's there, to differentiate between ELF and MachO. Supposing that people do write triples like "arm-elf-eabi", we should fix the behaviour. If not, we should just forbid such cases, as they will create confusion and we're not making a good default choice on them. There are two obvious ways to solve this: 1. Put ELF, MachO, COFF whatever in its own class. That would be a big change and only worthy if there is a big concern, which I don't think there is. 2. Analyse all tokens, and decide which to use, or use them all. This is a weird implementation and might create corner cases which we don't account for now. I'm open to ideas.
(In reply to comment #1) > It seems that this only happens when you chose a triple that has both ELF > and EABI, since both are considered "environments". > > The "arm-elf-eabi" triple is normalized to "armv4t---elf-eabi", since "elf" > is a valid environment, it completely ignores the EABI portion. > > Since I could have ELF files with any ABI in it, making ELF an environment > doesn't make much sense, though I can see it's there, to differentiate > between ELF and MachO. > > Supposing that people do write triples like "arm-elf-eabi", we should fix > the behaviour. If not, we should just forbid such cases, as they will create > confusion and we're not making a good default choice on them. > > There are two obvious ways to solve this: > > 1. Put ELF, MachO, COFF whatever in its own class. That would be a big > change and only worthy if there is a big concern, which I don't think there > is. I did do this a while back. Triple has an ObjectFormat field that indicates what the format is. This is a worthy concern IMO, and is really available. getObjectFormat and getEnvironment should return the necessary information. Am I misunderstanding something and something else is needed in order to support that? > 2. Analyse all tokens, and decide which to use, or use them all. This is a > weird implementation and might create corner cases which we don't account > for now. > > I'm open to ideas.
Hi Saleem, I believe this is only a concern to FreeBSD, which uses elf, rather than Linux, which doesn't. If you want to have a go at this, using the infrastructure you created, please do. I believe the hardest part will be to make sure all the unknown corner cases are dealt with, since I don't believe we have tests for all of them. I suggest you create a single patch that does the job, plus tests, and let everyone know in the list, so that if they start seeing weird behaviour in their platforms, they know what broke and it'll be easy to revert. cheers, --renato
This is a non-issue, since triples are not meant to mean anything. If/when we have a real issue with this odd behaviour, we can re-open the bug.