On Tue, Aug 04, 2015 at 07:26:19PM +0200, Kai Wasserbäch wrote:
> > Thanks that was really helpful. It looks like the real problem is the
> > parsing of the relocation section. Would it be possible for you to dump
> > the ELF image that is being parsed in radeon/radeon_elf_util.c
> > (radeon_elf_read) Maybe just by adding the following just before the
> > elf_memory () call:
> > int dfd = creat ("/tmp/dump.elf", 00755);
> > write (dfd, elf_buffer, elf_size);
> > close (dfd);
>
> I guarded this with a environment variable and replaced creat(), which is
> deprecated AFAIR, with open().
>
> Then I ran the test. Instead of just running through it didn't exit by itself.
> After a few minutes I killed it (size of dump.elf didn't change).
It is an actual ELF image, so that is good.
(It is slightly odd because the .AMDGPU.disasm section says it is a NOTE
section, but really isn't, it seems to just be plain string data. I don't
think that is the problem though, just makes it slightly harder to look
at it with tools like eu-readelf.)
But I wonder if it actually is the correct ELF image. I was expecting to
see at least an ".text.rel" section in it because the crash seems to have
to do with applying the relocations to the text section. But this dump.elf
file doesn't have one. And also...
> In addition to the ELF dump, I added a shader dump, which radeonsi can
> produce.
I see there are multiple shaders. If I look at the elf.dump I see
eu-readelf --strings=.AMDGPU.disasm dump.elf
String section [7] '.AMDGPU.disasm' contains 441 bytes at offset 0x18c:
[ 0]- s_mov_b32 m0, s9 ; BEFC0309
v_interp_mov_f32 v0, P0, 0, 0, [m0] ; C8020002
v_interp_mov_f32 v1, P0, 1, 0, [m0] ; C8060102
v_cvt_pkrtz_f16_f32_e32 v0, v0, v1 ; 5E000300
v_interp_mov_f32 v1, P0, 2, 0, [m0] ; C8060202
v_interp_mov_f32 v2, P0, 3, 0, [m0] ; C80A0302
v_cvt_pkrtz_f16_f32_e32 v1, v1, v2 ; 5E020501
exp 15, 0, 1, 1, 1, v0, v1, v0, v1 ; F8001C0F 01000100
s_endpgm ; BF810000
Which seems to match the last Shader Disassembly.
Since there are multiple I am wondering if this dump.elf is the right
one. I assume there are actually multiple created and we are looking
for one with an .rel.text section in it. Does that make sense?
Could you see if you could hack up the code to dump each one to a
new different file? Maybe just replace the open with something like
char tname[] = "dump.elf.XXXXXX";
dfd = mkstemp (tname);
Sorry for the somewhat cumbersome debugging session.
Thanks,
Mark
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
