[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #8 from Richard Earnshaw --- Perhaps something is changing the decision on the use of the frame pointer.
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #7 from Christophe Lyon --- Indeed, but I am surprised it seems to compile for cortex-m4?
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 Richard Earnshaw changed: What|Removed |Added Last reconfirmed||2022-09-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Richard Earnshaw --- In Thumb code r7 is the frame pointer, so can't be used in inline assembler without a dance whenever the frame pointer might be needed. I'm surprised this hasn't shown up before. We're going to need a separate definition of this macro when compiling for Thumb as you can't easily rewrite this. The code will need to do something like mov scratch, r7 mov r7, # svc 0 mov r7, scratch
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #5 from Christophe Lyon --- Could you share the preprocessed source file in the M3 and M4 cases along with the full command line used to compile it?
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #4 from Thomas Petazzoni --- Yes, same triplet. We do not (yet) have FDPIC support for ARM in Buildroot (we have a patch series pending for that).
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #3 from Christophe Lyon --- Interesting Did you use the same target triplet? arm*-*-uclinuxfdpiceabi is handled differently from arm-buildroot-uclinux-uclibcgnueabi
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032 --- Comment #2 from Thomas Petazzoni --- Thanks for the feedback. There must be something special in those configurations, because I did build a Cortex-M4 configuration with gcc 11.3.0 just a few days ago, and it built fine.
[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #1 from Christophe Lyon ---
At quick glance, I think this is caused by the definition of CLEAR_INSN_CACHE
in gcc/config/arm/uclinux-eabi.h:
/* Clear the instruction cache from `beg' to `end'. This makes an
inline system call to SYS_cacheflush. */
#undef CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END) \
{ \
register unsigned long _beg __asm ("a1") = (unsigned long) (BEG); \
register unsigned long _end __asm ("a2") = (unsigned long) (END); \
register unsigned long _flg __asm ("a3") = 0; \
register unsigned long _scno __asm ("r7") = 0xf0002; \
__asm __volatile ("swi 0x0@ sys_cacheflush" \
: "=r" (_beg) \
: "0" (_beg), "r" (_end), "r" (_flg), "r" (_scno)); \
}
which makes explicit use of r7.
This code has been like that since it was committed in 2007
So I suspect nobody ever tried to build this configuration.
