lm32 build problem.
version: 4.9.1 host compiler: gcc-4.8.2 host OS: Ubuntu 14.04 target: lm32-unknown-elf Here's the problem I see: tm@tm-VirtualBox:~/lm32-toolchain/lm32-gcc$ ../gcc-4.9.1/configure --prefix=/home/tm/bin --target=lm32-uclibc-elf --enable-languges=c ; make ... checking if /home/tm/lm32-toolchain/lm32-gcc/./gcc/xgcc -B/home/tm/lm32-toolchain/lm32-gcc/./gcc/ -B/home/tm/bin/lm32-uclibc-elf/bin/ -B/home/tm/bin/lm32-uclibc-elf/lib/ -isystem /home/tm/bin/lm32-uclibc-elf/include -isystem /home/tm/bin/lm32-uclibc-elf/sys-includesupports -c -o file.o... (cached) yes checking whether the /home/tm/lm32-toolchain/lm32-gcc/./gcc/xgcc -B/home/tm/lm32-toolchain/lm32-gcc/./gcc/ -B/home/tm/bin/lm32-uclibc-elf/bin/ -B/home/tm/bin/lm32-uclibc-elf/lib/ -isystem /home/tm/bin/lm32-uclibc-elf/include -isystem /home/tm/bin/lm32-uclibc-elf/sys-includelinker (/home/tm/lm32-toolchain/lm32-gcc/./gcc/collect-ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1
mips-elf-gcc -fno-delayed-branch problem
target: mips-elf
version: 4.4.1
There's a problem where compiling code with -fno-delayed-branch still fills
branch delay slots.
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1097 % cat minlib.c
#include
int printf(const char *format, ...)
{
register int a0 asm ("a0");
register int a1 asm ("a1");
register int a2 asm ("a2");
va_list ap;
va_start(ap, format);
a0 = 2;
a1 = (int)format;
a2 = (int)ap;
__asm__ volatile ("nop; nop; syscall; nop" : : "r" (a0), "r" (a1), "r"
(a2));
va_end(ap);
}
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1098 % mips-elf-gcc -O2
-fno-delayed-branch -c minlib.c -o minlib.o
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1099 % mips-elf-objdump
--disassemble minlib.o
minlib.o: file format elf32-bigmips
Disassembly of section .text:
:
0: 27bdfff8addiu sp,sp,-8
4: 27a2000caddiu v0,sp,12
8: afa5000csw a1,12(sp)
c: afa60010sw a2,16(sp)
10: 00802821movea1,a0
14: afa70014sw a3,20(sp)
18: afa2sw v0,0(sp)
1c: 00403021movea2,v0
20: 24040002li a0,2
...
2c: 000csyscall
30: nop
34: 03e8jr ra
38: 27bd0008addiu sp,sp,8<- branch delay slot
filled
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1100 %
The problem appears to be caused with GNU AS. It now has the capability to
reorder instructions, and there is no ".set noreorder" emitted by the compiler,
so the assembler fills the branch delay slot.
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1104 % cat test.s
.text
addiu $sp,$sp,8
jr $ra
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1105 % mips-elf-as test.s -o
test.o
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1106 % mips-elf-objdump
--disassemble test.o
test.o: file format elf32-bigmips
Disassembly of section .text:
<.text>:
0: 03e8jr ra
4: 27bd0008addiu sp,sp,8
[ubxju10]/home/jupiter/tmorita/dhrystone/test 1107 %
So when the -fno-delayed-branch switch is passed to mips-elf-gcc, a ".set
noreorder" directive should be emitted into the assembly file.
Toshi
Re: mips-elf-gcc -fno-delayed-branch problem
Maybe GAS could recognize -fno-delayed-branch to selectively disable branch slot filling? Is there a list of optimizations performed by MIPS GAS listed somewhere? It would be nice if these could be selectively enabled. Toshi --- On Thu, 5/19/11, Richard Sandiford wrote: > From: Richard Sandiford > Subject: Re: mips-elf-gcc -fno-delayed-branch problem > To: "Toshi Morita" > Cc: gcc@gcc.gnu.org > Date: Thursday, May 19, 2011, 1:03 AM > Toshi Morita > writes: > > There's a problem where compiling code with > -fno-delayed-branch still > > fills branch delay slots. > > [...] > > The problem appears to be caused with GNU AS. It now > has the > > capability to reorder instructions, and there is no > ".set noreorder" > > emitted by the compiler, so the assembler fills the > branch delay slot. > > FWIW, I think this was a deliberate historical > choice. But... > > > So when the -fno-delayed-branch switch is passed to > mips-elf-gcc, a > > ".set noreorder" directive should be emitted into the > assembly file. > > The problem is that ".set noreorder" has other side-effects > too, > such as stopping the assembler from inserting nops to avoid > data > hazards, or to work around errata. There are various > situations > in which we can't rely on GCC to insert these nops, and in > which > GCC must therefore treat the function as ".set reorder". > > One of those situations is when the function has inline > asm, as in > your example. GCC doesn't know what the inline asm > does, so it also > doesn't know what nops would be needed between the asm and > the > GCC-generated code, or within the asm code itself. > Another situation > is when compiling with -mno-explicit-relocs or with various > -mfix-* > options. While those are somewhat niche options, it'd > be inconsistent > to "guarantee" that -fno-delayed-branch emits everything as > ".set noreorder" > except when those options are used. > > At the moment, the way to force no delayed branches is to > use: > > -fno-delayed-branch -Wa,-O0 > > Maybe it would be worth breaking with tradition and making > -fno-delayed-branch imply -Wa,-O0 though. Back in the > day, > the assembler's version of delayed-branch filling was > applied > to pretty much every function, so the separation was > probably > more obvious. However, CCC now tries to emit most > functions as > ".set noreorder"/ ".set nomacro", so -fno-delayed-branch > does > actually stop the assembler filling branches in most > situations. > I can see that it'd be confusing to suddenly have the > assembler > kick in when you add something like an inline asm. > > So yeah, I'll try to get around to that this weekend... > > Richard >
Re: mips-elf-gcc -fno-delayed-branch problem
The -O1 sounds like a reasonable choice. Thanks for looking at the problem. Toshi --- On Sat, 5/21/11, Richard Sandiford wrote: > From: Richard Sandiford > Subject: Re: mips-elf-gcc -fno-delayed-branch problem > To: "Toshi Morita" > Cc: gcc@gcc.gnu.org > Date: Saturday, May 21, 2011, 12:37 AM > Toshi Morita > writes: > > Maybe GAS could recognize -fno-delayed-branch to > selectively disable > > branch slot filling? > > I'd agree if it was -mno-delayed-branch. I think -f* > options are > generally compiler options, while -m* options are target > options that > could in principle be passed down to either the assembler > or the linker. > > > Is there a list of optimizations performed by MIPS GAS > listed somewhere? > > It would be nice if these could be selectively > enabled. > > The only other optimisation (if it can even be called that) > is increased > accuracy regarding nop insertion. Suppose we have > something like: > > .text > lw $4,foo > addiu $5,$5,1 > jr $31 > .data > foo: > .word 1 > > When GAS sees the LW, it doesn't know whether the LW should > use a > HI/LO pair or a GP-relative access. It therefore > creates a variant > "frag" that describes both possibilities. As far as > GAS is concerned, > the following ADDIU starts a new subblock of code. > > With -Wa,-O0, GAS doesn't try to handle dependencies > between these subblocks, > and just assumes the worst. So if you assemble with > -mips1, GAS has to > assume that the next subblock after the LW might use $4 > straight away, > and that a nop is needed: > > <.text>: > 0: 3c04 > lui a0,0x0 > > 0: R_MIPS_HI16 .data > 4: 8c84 > lw a0,0(a0) > > 4: R_MIPS_LO16 .data > 8: > nop > c: 24a50001 > addiu a1,a1,1 > 10: 03e8 > jr ra > 14: > nop > > At -Wa,-O1 and above it does the sensible thing: > > <.text>: > 0: 3c04 > lui a0,0x0 > > 0: R_MIPS_HI16 .data > 4: 8c84 > lw a0,0(a0) > > 4: R_MIPS_LO16 .data > 8: 24a50001 > addiu a1,a1,1 > c: 03e8 > jr ra > 10: > nop > > TBH, I think the cases where you'd want the -O0 behaviour > are > vanishingly rare. It does in principle need less > memory, and does > in principle assemble slightly quicker, but I don't think > anyone would > notice unless they looked hard. > > So -Wa,-O1 is better than the -Wa,-O0 that I mentioned > previously. > > Richard >
Re: -mfmovd enabled by default for SH2A but not for SH4
Naveen H.S. wrote: > SH2A, SH4 and SH4A FPU targets support mode switching i.e. switching > between single precision and double precision. Double-precision FPU > is also available for the above mentioned targets. > > The option "-mfmovd" is enabled by default for SH2A which generates > "fmov.d" instruction by default. However, SH4 and SH4A targets > generates "fmov.d" instruction only after passing the option "-mfmovd". > > Can somebody clarify the reason behind above implementation? > The instruction "fmov.d" may generate "address error" exception in > some cases as the address involved in "fmov.d" instruction is not > always 8 byte aligned. This problem can be easily resolved by passing > option "-mdalign"(aligns double on 8 byte boundary). It's been a while since I've worked on the SH4, but from what I remember, there are two problems: First, fmovd doesn't work properly on the SH4 in little-endian mode. In little-endian mode, it loads the two 32-bit values swapped, so if the value in memory is 0x0123456789abcdef, you get 0x89abcdef01234567 instead. Second, -mdalign only affects alignment of statically allocated variables, and does not affect stack alignment. So, 64-bit values on the stack are not guaranteed to be 64-bit aligned even with -mdalign. Toshi Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Calling functions through a pointerI
This isn't a GCC question specifically - it's more of a C language question. I'm involved in a discussion involving C language function pointers. The other party claims calling functions through a function pointer is "undefined behavior" because it's not specifically mentioned in the C language spec. This seems silly, because this is a common language feature used by bytecode interpreters, JITs, etc. Can someone clarify that calling functions through a function pointer is not "undefined behavior"? Thanks in advance. Toshi
