I just dumped the symbols, wow your's includes a lot of extra stuff. I see you are setting the clock but not much more than that vs my example. The clock seems to have sucked in a lot of extra string functionality as well as time functions. I think you may well have used different compiler command line settings. This is what I used to build my elf file.
EDIT: yep after using this on your source I get the symbols in out2.txt which is a smaller image vs your original .elf file dumped in out.txt. It might be the --gc-sections option doing this. EDIT2: yes it is that option which makes the difference.
32k for a hello world is still ridiculous.
I always find it annoying that the typical compiler->linker arrangement is unable to really provide readable listings that actually correspond to the output binary. Very hard to figure out what's actually in your code.
@Rayman said:
@rogloh Guess I can look at what you posted in other thread, but...
Are the changes you made just to the lib files? Or, to the main LLVM files too?
Details are in the other thread so best to read it. But yes it has changes to the libs (which is what I provided you), and also to LLVM source which needs fixes for the C modulus "%" operation otherwise it crashes LLVM, and also other CORDIC dependency fixes etc. You really should take those file changes and update your own LLVM build to resolve theses. Also there are still cases if you disassemble random bytes say with llvm-objdump -D it will crash this tool because the disassembler doesn't know about ALL P2 instructions yet. But if you disassemble genuine P2 compiled C code with llvm-objdump -d it's fine.
@Wuerfel_21 said:
32k for a hello world is still ridiculous.
Often the case with C with libs included.
I always find it annoying that the typical compiler->linker arrangement is unable to really provide readable listings that actually correspond to the output binary. Very hard to figure out what's actually in your code.
I find in this case that objdump -d is generally okay. I get a good disassembly listing of all P2 code in the binary. But if you wanted to see the symbols for global data accesses you don't see them used in the code it's just absolute read/write hex addresses which is not nice. You only see data symbols and their addresses in the symbol table. They really should cross reference them back in the disassembly listing IMO, or maybe that's just not implemented in the P2 port right now. Also it'd be real nice to have a way in the listing to see which C function arguments are being accessed in the stack frame or which initial registers they get copied into by somehow referring them back to the source code. Bit tricky if they don't have a way to carry it through in the .elf file. From memory I think enabling debugging helps pass more info down through the intermediate files.
Comments
I just dumped the symbols, wow your's includes a lot of extra stuff. I see you are setting the clock but not much more than that vs my example. The clock seems to have sucked in a lot of extra string functionality as well as time functions. I think you may well have used different compiler command line settings. This is what I used to build my elf file.
clang -I. -I../.. -Ibuild -Wall -Werror --target=p2 -fno-jump-tables -c -fdata-sections -ffunction-sections -o main.o main.c
clang -v --target=p2 -Wl,--gc-sections -Wl,-L/Users/roger/Applications/p2llvm/libc/lib -Wl,-L/Users/roger/Applications/p2llvm/libp2/lib -o main.elf main.o
EDIT: yep after using this on your source I get the symbols in out2.txt which is a smaller image vs your original .elf file dumped in out.txt. It might be the --gc-sections option doing this. EDIT2: yes it is that option which makes the difference.
Last time when through this, was told that the .elf doesn't really reflect the size of the actual binary...
Seems you have to convert the .elf to a .bin to see exactly how big it is on chip?
Used web search to figure out how to convert .elf to .bin
Build in the way from post#32 above and size is smaller...
@rogloh Guess I can look at what you posted in other thread, but...
Are the changes you made just to the lib files? Or, to the main LLVM files too?
32k for a hello world is still ridiculous.
I always find it annoying that the typical compiler->linker arrangement is unable to really provide readable listings that actually correspond to the output binary. Very hard to figure out what's actually in your code.
(don't read this post as me being all negative!)
@Wuerfel_21 code is posted above…
Would be interesting to compare binary size with Flexprop…
Details are in the other thread so best to read it. But yes it has changes to the libs (which is what I provided you), and also to LLVM source which needs fixes for the C modulus "%" operation otherwise it crashes LLVM, and also other CORDIC dependency fixes etc. You really should take those file changes and update your own LLVM build to resolve theses. Also there are still cases if you disassemble random bytes say with
llvm-objdump -Dit will crash this tool because the disassembler doesn't know about ALL P2 instructions yet. But if you disassemble genuine P2 compiled C code withllvm-objdump -dit's fine.Often the case with C with libs included.
I find in this case that
objdump -dis generally okay. I get a good disassembly listing of all P2 code in the binary. But if you wanted to see the symbols for global data accesses you don't see them used in the code it's just absolute read/write hex addresses which is not nice. You only see data symbols and their addresses in the symbol table. They really should cross reference them back in the disassembly listing IMO, or maybe that's just not implemented in the P2 port right now. Also it'd be real nice to have a way in the listing to see which C function arguments are being accessed in the stack frame or which initial registers they get copied into by somehow referring them back to the source code. Bit tricky if they don't have a way to carry it through in the .elf file. From memory I think enabling debugging helps pass more info down through the intermediate files.main.elf: file format elf32-p2 Disassembly of section .text: 00000000 <__entry>: 0: f8 a1 03 fb rdlong r0, ptra 4: 10 00 80 fd jmp #\16 ... 00000040 <__start0>: 40: f8 a1 03 fb rdlong r0, ptra 44: 98 00 00 ff augs #152 48: 28 a1 07 f6 mov r0, #296 4c: d0 a1 03 fb rdlong r0, r0 50: 02 a0 97 fb tjz r0, #2 54: 00 00 90 ff augd #1048576 58: 00 fe 65 fd hubset #255 5c: 00 00 00 ff augs #0 60: 68 a0 07 f6 mov r0, #104 64: d0 01 e8 fc coginit #0, r0 00000068 <__start>: 68: f8 a1 03 fb rdlong r0, ptra 6c: 98 00 00 ff augs #152 70: 38 a5 07 f6 mov r2, #312 74: 29 fe 67 fd setq2 #511 78: 01 00 00 ff augs #1 7c: 00 00 04 fb rdlong $0x000, #0