Skip to content

Commit

Permalink
more work on pop {pc} and narrowing in on the bug with llvm optimized…
Browse files Browse the repository at this point in the history
… code
  • Loading branch information
dwelch67 committed Jul 9, 2013
1 parent 6aa8663 commit 7a946a5
Show file tree
Hide file tree
Showing 3 changed files with 37 additions and 10 deletions.
26 changes: 23 additions & 3 deletions picojpeg/Makefile
@@ -1,5 +1,5 @@

all : host gpicojpegtest.bin lpicojpegtest.bin
all : host gpicojpegtest.bin lpicojpegtest.bin xpicojpegtest.bin

host : host.c picojpeg.c picojpeg.h jpegdata.h
gcc -O2 host.c picojpeg.c -o host
Expand Down Expand Up @@ -34,7 +34,8 @@ AOPS = --warn --fatal-warnings

OOPS = -std-compile-opts -strip-debug -disable-simplify-libcalls
LOPS = -Wall -m32 -emit-llvm -disable-simplify-libcalls
LLCOPS = -march=thumb -disable-simplify-libcalls
LLCOPS = -march=thumb -disable-simplify-libcalls -mattr=v5t



xall : gpicojpegtest.bin lpicojpegtest.bin
Expand Down Expand Up @@ -80,9 +81,28 @@ lpicojpegtest.bin : memmap vectors.o putget.o embedded.bc picojpegtest.bc picojp
opt $(OOPS) lpicojpegtest.raw.bc -o lpicojpegtest.bc
#llc $(LLCOPS) lpicojpegtest.bc -o lpicojpegtest.s
#$(ARMGNU)-as lpicojpegtest.s -o lpicojpegtest.o
llc $(LLCOPS) lpicojpegtest.raw.bc -filetype obj -o lpicojpegtest.o
llc $(LLCOPS) lpicojpegtest.bc -filetype obj -o lpicojpegtest.o
#llc $(LLCOPS) lpicojpegtest.raw.bc -filetype obj -o lpicojpegtest.o
$(ARMGNU)-ld -T memmap vectors.o putget.o lpicojpegtest.o -o lpicojpegtest.elf
$(ARMGNU)-objdump -D lpicojpegtest.elf > lpicojpegtest.list
$(ARMGNU)-objcopy lpicojpegtest.elf -O binary lpicojpegtest.bin


xpicojpegtest.bin : memmap vectors.o putget.o embedded.bc picojpegtest.bc picojpeg.bc uart.bc
#opt $(OOPS) embedded.bc -o embedded.opt.bc
#opt $(OOPS) picojpeg.bc -o picojpeg.opt.bc
#opt $(OOPS) picojpegtest.bc -o picojpegtest.opt.bc
#opt $(OOPS) uart.bc -o uart.opt.bc
#llc $(LLCOPS) embedded.opt.bc -filetype obj -o xembedded.o
llc $(LLCOPS) picojpeg.bc -filetype obj -o xpicojpeg.o
#llc $(LLCOPS) picojpegtest.opt.bc -filetype obj -o xpicojpegtest.o
#llc $(LLCOPS) uart.opt.bc -filetype obj -o xuart.o
llvm-link embedded.bc picojpegtest.bc uart.bc -o xpicojpegtest.raw.bc
opt $(OOPS) xpicojpegtest.raw.bc -o xpicojpegtest.bc
llc $(LLCOPS) xpicojpegtest.bc -filetype obj -o xpicojpegtest.o
#$(ARMGNU)-ld -T memmap vectors.o putget.o xembedded.o xpicojpeg.o xpicojpegtest.o xuart.o -o xpicojpegtest.elf
$(ARMGNU)-ld -T memmap vectors.o putget.o xpicojpegtest.o xpicojpeg.o -o xpicojpegtest.elf
$(ARMGNU)-objdump -D xpicojpegtest.elf > xpicojpegtest.list
$(ARMGNU)-objcopy xpicojpegtest.elf -O binary xpicojpegtest.bin


17 changes: 12 additions & 5 deletions picojpeg/README
Expand Up @@ -6,10 +6,15 @@ things with thumbulator.
The llvm toolchain uses mov lr,pc which on the surface is a bad thing
if you want to use that lr as a return address for example because
the program counter does not have the lsbit set, but the link register
should contain the lsbit set if the return address is a thumb addres.
Now the llvm tools also generated a push with lr and pop with pc
instead of popping what was pushed as the lr into something (r0-r7) and
then bx to that register.
should contain the lsbit set if the return address is a thumb address.

Now the llvm tools also generated a push with lr and pop with pc. This
also looks bad on initial inspection, but the ARM ARM says that for
armv4T the pop {pc} is like a mov pc,value which means the address does
not need the lsbit set, but must be an address to thumb code for armv5t
and newer the pop {pc} is instead like a bx address, which needs the
lsbit set but is more flexible. So thumbulator warns if it sees a
pop {pc} with the lsbit not set but keeps going.

Likewise gcc had a situation where the program counter was a destination
without the lsbit being set. This is okay as the pc doesnt need to
Expand All @@ -18,4 +23,6 @@ for a compiler to generate those instructions. I removed the trap and
the program worked fine.

At the moment the llvm optimized build does not work with thumbulator
I dont know if that is thumbulator or llvm. I am using llvm 3.3
I believe this is a thumbulator problem as it compiles and runs on
real ARM hardware but so far not an apples to apples comparison. I am
using llvm 3.3 (seem my build_gcc repo, the build_clang script).
4 changes: 2 additions & 2 deletions thumbulator.c
Expand Up @@ -1454,7 +1454,7 @@ if(DISS) fprintf(stderr,"mov r%u,r%u\n",rd,rm);
rc=read_register(rm);
if((rd==14)&&(rm==15))
{
//printf("mov lr,pc\n");
//printf("mov lr,pc warning 0x%08X\n",pc-2);
rc|=1;
}
if(rd==15)
Expand Down Expand Up @@ -1570,7 +1570,7 @@ if(DISS)
if((rc&1)==0)
{
fprintf(stderr,"pop {rc} with an ARM address pc 0x%08X popped 0x%08X\n",pc,rc);
exit(1);
//exit(1);
}
rc+=2;
write_register(15,rc);
Expand Down

0 comments on commit 7a946a5

Please sign in to comment.