Oups, I misspelled it in the topic title.
Here is the exact way I tried:
clBuildProgram(FProgram,1,@OwnerDevice.FDeviceId,'-save-temps='+tempDir+'\cl -fno-bin-source -fno-bin-llvmir -fno-bin-amdil',....
This builds an opencl elf wich contains only the binary section in it. And this happens:
before 13.4: It produces the disassembled .isa textfile at the specified path.
13.4: It produces no temporary files at all.
I'm not sure if it's either a security thing or a bug.
For security reasons I think it can make harder to reverse-engineer a binary_only .elf file. But it is also makes harder to develop an assembler or a machine code generator because most of the instruction encodings can be learnt from the built in disassembler feature.
From now the disassembler is only works for instructions generated by amd_il, and it can't disassemble any binary stream.
I asked some people, and it looks the option should work. I had checked " -save-temps " in clBuildProgram API, and could generate the intermediate files using the internal drivers on a linux machine. Can you please try to generate the files in the executable folder or to give the complete path for the intermediate files. I have not checked with 13.4 driver and windows yet, will try in case the issue still exists.
I'm saving it into a specified path: '-save-temps=c:\$ocl_tmp\cl -fno-bin-source -fno-bin-llvmir -fno-bin-amdil -fbin-exe'
It ONLY FAILS when I use 13.4 AND give it an .elf with only the executable section in it. If I give it an elf containing only an .il section or only an OpenCL section, then it works fine.
Sorry I can't try local directory right now, as I don't have 13.4 too.
I am able to generate intermediate files using Win7 and catalyst 13.4 for APP SDK Samples. As you mentioned the save-temps option is not working when only executable section of the ELF is passed to it. Can you tell some steps to do this?
I was thinking of using --dump option with "-fno-bin-llvmir -fno-bin-amdil" flags. And then loading the binary generated via the dump process. Can you confirm whether this method is appropriate.
Hi, thanks for spending your time on this!
Here are the steps:
0. win7 64bit, cat 13.4
1. Download this small test kernel -> http://x.pgy.hu/~worm/het/disasm_test.zip /test.elf (note this kernel is for Capeverde, and it runs perfectly)
2. Call clCreateProgramWithBinary() to upload it to OpenCL
3. Call clBuildProgram() with "-save-temps=c:\$ocl_tmp\cl -fno-bin-source -fno-bin-llvmir -fno-bin-amdil -fbin-exe" parameters. (you'll need Admin rights to do this)
4. Check c:\$ocl_tmp dir and there will be nothing.
If you do the above on cat12.10, then you'll find an .isa file containing 11 disassembled gcn assembly instructions.
Additional info: The following things still works on 13.4:
- the http://x.pgy.hu/~worm/het/disasm_test.zip /test_il.elf file is an .elf that contains only an il file. If you give it to clCreateProgramWithBinary(), clBuildProgram(with above exe-only commandline), and then -> .il, .isa files will be generated.
- also if you compile an opencl file with clCreateProgramWithSource(), clBuildProgram(with above exe-only commandline), then -> .il, .isa, .ocl files are generated
Only in cases when an executable only .elf is given to clCreateProgramWithBinary(), clBuildProgram() will refuse to generate .isa disassembled image.
Thanks for the steps. But out of curiosity, i am interested in knowing, how to create the elf file with just binary. The method i had explained was also not producing any intermediate files with 13.4 driver. Also a normal OpenCL kernel was producing il, isa files as expected.
Checking with 12.10 driver will be a bit of a work for me too.
You can upload anything with clCreateProgram* including: - OpenCL source, .elf with only IL section in it.
Then you can use clBuildProgram with the flags -fno-bin-source -fno-bin-llvmir -fno-bin-amdil -fbin-exe to generate an Executable only .elf. At this point if you use -save-temps, it will generate the opencl, il and isa files.
After that you have an .elf that only contains the executable section. If you load it with clCreateProgram, and then ask clBuildProgram with -save-temps, it will not generate the .isa disasm (13.4 fails, 12.10 works fine).
The example files I linked:
test_il.elf -> it's an elf containing a small amd_il code, 10 lines of code.
test.elf -> whis is what clCreateProgramWithBinary() and clBuildProgram() compiled from test_il.elf with the -no-source -no-llvmir -no-amdil -yes-exe flags.
Both .elfs are tested and running prefectly but on 13.4 but only the amd_il elf can be disassembled (even there is no isa in it). The isa-only elf cannot be disassembled.
Important! These test.elf is for 13.4 and incompatible with previous catalysts!!!
On 12.10 everything I'm talking about is working good, don't even need to check it.
So the simplest test sequence is: OpenCL test program -> compile to executable only .elf -> save the .elf -> load it with a new clCreateProgram/clBuildProgram with -save-temps -> NO .ISA file generated on cat 13.4.
I reinstalled 10.12 and generated an executable only test.elf. http://x.pgy.hu/~worm/het/test_12.10_gcn.elf
If you load it with clCreatePrg() and clBuildPrg( -save-temps ) you should find this disasm in the save-temps path:
; -------- Disassembly --------------------
s_mulk_i32 s16, 0x0100 // 00000000: B8100100
v_add_i32 v0, vcc, s16, v0 // 00000004: 4A000010
s_buffer_load_dword s0, s[8:11], 0x00 // 00000008: C2000900
s_buffer_load_dword s1, s[12:15], 0x00 // 0000000C: C2008D00
s_waitcnt lgkmcnt(0) // 00000010: BF8C007F
v_mad_u32_u24 v2, v0, 4, s0 // 00000014: D2860002 00010900
v_add_i32 v3, vcc, s1, v0 // 0000001C: 4A060001
tbuffer_store_format_x v3, v2, s[4:7], 0 offen format:[BUF_DATA_FORMAT_32,BUF_NUM_FORMAT_FLOAT] // 00000020: EBA41000 80010302
s_endpgm // 00000028: BF810000
Thanks. Will try it tomorrow
Worked on it, and i do see the issue. I will attach my code soon.
Anyways I was thinking why were you trying to generate Dis-assembled files from binary only elf files?
Hi and thanks!
Why: My GCN ISA assembler produces binary only files and the disassembler is the best feedback on what it does. Good to see the code disassembled by an official(!) tool before I send it to the card. In other words the disasm it's the most accurate 'documentation' on the GCN architecture. When there was no ISA documentation out yet (in 2012 1st half) the disassembler was the actual Southern Islands ISA documentation.
Also there are some other people out there who like to use your excellent hardware in the most efficient way (in binary ISA), but this disassembler restriction just makes us blind.
It's a choice between:
- Not using the latest driver
- Writing an own disasm (which would be a waste of time as AMD already has a good one )