Bug 63632

I am still getting segfaults with updated mesa/llvm, though the bt is a bit different.

I can reproduce with a new 64 bit LFS and an old 32 bit one.

Have put RV790 back in this box so it's not just RS880.

Program received signal SIGSEGV, Segmentation fault.
0xb6451433 in r600_llvm_compile (mod=0x80658c0, inst_bytes=inst_bytes@entry=0xbfffa7d4, inst_byte_count=inst_byte_count@entry=0xbfffa7d8, family=CHIP_RV770, ngpr=0x806425c, dump=dump@entry=0) at r600_llvm.c:567
567             *ngpr = util_le32_to_cpu(*(uint32_t*)binary.config);
(gdb) bt
#0  0xb6451433 in r600_llvm_compile (mod=0x80658c0, inst_bytes=inst_bytes@entry=0xbfffa7d4, inst_byte_count=inst_byte_count@entry=0xbfffa7d8, family=CHIP_RV770, ngpr=0x806425c, dump=dump@entry=0) at r600_llvm.c:567
#1  0xb6433f16 in r600_shader_from_tgsi (rscreen=0x8074cf0, pipeshader=pipeshader@entry=0x8064230, key=...) at r600_shader.c:1464
#2  0xb6435135 in r600_pipe_shader_create (ctx=ctx@entry=0x805b850, shader=0x8064230, key=...) at r600_shader.c:132
#3  0xb6448f6b in r600_shader_select (ctx=ctx@entry=0x805b850, sel=sel@entry=0x8094230, dirty=dirty@entry=0x0) at r600_state_common.c:747
#4  0xb6449134 in r600_create_shader_state (ctx=0x805b850, state=<optimized out>, pipe_shader_type=0) at r600_state_common.c:794
#5  0xb633d0a3 in ureg_create_shader (ureg=ureg@entry=0x808f8f0, pipe=pipe@entry=0x805b850, so=so@entry=0x0) at tgsi/tgsi_ureg.c:1701
#6  0xb636a434 in ureg_create_shader_with_so_and_destroy (so=0x0, pipe=0x805b850, p=0x808f8f0) at ./tgsi/tgsi_ureg.h:131
#7  util_make_vertex_passthrough_shader_with_so (pipe=pipe@entry=0x805b850, num_attribs=num_attribs@entry=2, semantic_names=semantic_names@entry=0xbffff16c, semantic_indexes=semantic_indexes@entry=0xbffff20c, so=so@entry=0x0) at util/u_simple_shaders.c:98
#8  0xb636a48f in util_make_vertex_passthrough_shader (pipe=pipe@entry=0x805b850, num_attribs=num_attribs@entry=2, semantic_names=semantic_names@entry=0xbffff16c, semantic_indexes=semantic_indexes@entry=0xbffff20c) at util/u_simple_shaders.c:64
#9  0xb634c604 in util_blitter_create (pipe=pipe@entry=0x805b850) at util/u_blitter.c:301
#10 0xb64248a1 in r600_create_context (screen=0x8074cf0, priv=0x0) at r600_pipe.c:466
#11 0xb6261a9b in st_api_create_context (stapi=0xb77752c0 <st_gl_api>, smapi=0x80747b0, attribs=0xbffff474, error=0xbffff470, shared_stctxi=0x0) at ../../src/mesa/state_tracker/st_manager.c:633
#12 0xb645777c in dri_create_context (api=API_OPENGL_COMPAT, visual=0x80787f8, cPriv=0x807fc28, major_version=1, minor_version=0, flags=0, error=0xbffff53c, sharedContextPrivate=0x0) at dri_context.c:124
#13 0xb611b89d in dri2CreateContextAttribs (screen=screen@entry=0x80746f8, api=api@entry=0, config=config@entry=0x80787f8, shared=shared@entry=0x0, num_attribs=num_attribs@entry=0, attribs=attribs@entry=0x0, error=error@entry=0xbffff53c, data=data@entry=0x807f518)
    at ../../../../src/mesa/drivers/dri/common/dri_util.c:288
#14 0xb611ba17 in dri2CreateNewContextForAPI (screen=screen@entry=0x80746f8, api=api@entry=0, config=config@entry=0x80787f8, shared=shared@entry=0x0, data=data@entry=0x807f518) at ../../../../src/mesa/drivers/dri/common/dri_util.c:306
#15 0xb611ba4f in dri2CreateNewContext (screen=0x80746f8, config=0x80787f8, shared=0x0, data=0x807f518) at ../../../../src/mesa/drivers/dri/common/dri_util.c:314
#16 0xb7f11209 in dri2_create_context (base=0x805b300, config_base=0x809ed70, shareList=0x0, renderType=32788) at dri2_glx.c:230
#17 0xb7ee73f9 in CreateContext (dpy=dpy@entry=0x804c050, generic_id=545, config=0x809ed70, shareList_user=shareList_user@entry=0x0, allowDirect=allowDirect@entry=1, code=code@entry=3, renderType=32788, screen=screen@entry=0) at glxcmds.c:274
#18 0xb7ee7c15 in glXCreateContext (dpy=0x804c050, vis=0x805b6b8, shareList=0x0, allowDirect=1) at glxcmds.c:379
#19 0xb7cb7c6a in __glutCreateWindow (parent=0x0, x=0, y=0, width=300, height=300, gameMode=0) at glut_win.c:609
#20 0xb7cb7e11 in glutCreateWindow (title=title@entry=0x804a900 "Gears") at glut_win.c:731
#21 0x0804906f in main (argc=1, argv=0xbffff7f4) at gears.c:391

I can't reproduce this with LLVM r179895 and Mesa 12eab7cc564a6928197f9b87ded9e368e56976f0

Have you done full rebuilds of both projects?

(In reply to comment #2)
> I can't reproduce this with LLVM r179895 and Mesa
> 12eab7cc564a6928197f9b87ded9e368e56976f0
> 
> Have you done full rebuilds of both projects?

Yes, I always do make [dist]clean and git clean -dfx.

I have just deleted both trees and re-cloned to be sure, but the segfault is still there.

When I was on my working commits moving either llvm or mesa to head while keeping the other on "working" produced the segfault (which is why I didn't do a proper bisect).

I always clean and rebuild mesa after llvm has changed.

(In reply to comment #3)
> (In reply to comment #2)
> > I can't reproduce this with LLVM r179895 and Mesa
> > 12eab7cc564a6928197f9b87ded9e368e56976f0
> > 
> > Have you done full rebuilds of both projects?
> 
> Yes, I always do make [dist]clean and git clean -dfx.
> 
> I have just deleted both trees and re-cloned to be sure, but the segfault is
> still there.
> 
> When I was on my working commits moving either llvm or mesa to head while
> keeping the other on "working" produced the segfault (which is why I didn't
> do a proper bisect).
> 
> I always clean and rebuild mesa after llvm has changed.

I was able to reproduce this on my gentoo system, but not on either of my fedora systems.  I will investigate further, what distro are you using?

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I can't reproduce this with LLVM r179895 and Mesa
> > > 12eab7cc564a6928197f9b87ded9e368e56976f0
> > > 
> > > Have you done full rebuilds of both projects?
> > 
> > Yes, I always do make [dist]clean and git clean -dfx.
> > 
> > I have just deleted both trees and re-cloned to be sure, but the segfault is
> > still there.
> > 
> > When I was on my working commits moving either llvm or mesa to head while
> > keeping the other on "working" produced the segfault (which is why I didn't
> > do a proper bisect).
> > 
> > I always clean and rebuild mesa after llvm has changed.
> 
> I was able to reproduce this on my gentoo system, but not on either of my
> fedora systems.  I will investigate further, what distro are you using?

I use linux from scratch and can reproduce on an old 32bit build and a more recent pure 64bit.

Which version of libelf is used in each case? I was running into problems with the one from http://www.mr511.de/software/ but the one from Fedora's elfutils works fine. Tom told me on IRC the former requires an additional initialization step.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I can't reproduce this with LLVM r179895 and Mesa
> > > 12eab7cc564a6928197f9b87ded9e368e56976f0
> > > 
> > > Have you done full rebuilds of both projects?
> > 
> > Yes, I always do make [dist]clean and git clean -dfx.
> > 
> > I have just deleted both trees and re-cloned to be sure, but the segfault is
> > still there.
> > 
> > When I was on my working commits moving either llvm or mesa to head while
> > keeping the other on "working" produced the segfault (which is why I didn't
> > do a proper bisect).
> > 
> > I always clean and rebuild mesa after llvm has changed.
> 
> I was able to reproduce this on my gentoo system, but not on either of my
> fedora systems.  I will investigate further, what distro are you using?

The problem on my gentoo system was that I had removed --enable-shared from my llvm configure script a few days ago, so I was still linking with an older LLVM.

Can you check that you are passing --enable-shared when configuring LLVM?

(In reply to comment #7)

> The problem on my gentoo system was that I had removed --enable-shared from
> my llvm configure script a few days ago, so I was still linking with an
> older LLVM.
> 
> Can you check that you are passing --enable-shared when configuring LLVM?

I wasn't, but passing it does not prevent the segfault - will look into libelf.

(In reply to comment #6)
> Which version of libelf is used in each case? I was running into problems
> with the one from http://www.mr511.de/software/ but the one from Fedora's
> elfutils works fine. Tom told me on IRC the former requires an additional
> initialization step.

On my old 32bit setup - haven't got a clue, it was ages ago :-)

On the 64 bit build I have only recently installed as it became required for llvm - I used the source from debian sid. Have now tried vanilla and with debian diff, but still segfault.

Will look in to Fedora version.

(In reply to comment #8)
> (In reply to comment #7)
> 
> > The problem on my gentoo system was that I had removed --enable-shared from
> > my llvm configure script a few days ago, so I was still linking with an
> > older LLVM.
> > 
> > Can you check that you are passing --enable-shared when configuring LLVM?
> 
> I wasn't, but passing it does not prevent the segfault - will look into
> libelf.

Is it the same segfault?  If the problem is libelf you will see a segfault in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or --with-llvm-shared-libs ?

(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > 
> > > The problem on my gentoo system was that I had removed --enable-shared from
> > > my llvm configure script a few days ago, so I was still linking with an
> > > older LLVM.
> > > 
> > > Can you check that you are passing --enable-shared when configuring LLVM?
> > 
> > I wasn't, but passing it does not prevent the segfault - will look into
> > libelf.
> 
> Is it the same segfault?  If the problem is libelf you will see a segfault
> in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
> --with-llvm-shared-libs ?

It is the same segfault as comment1.

I was building mesa with neither option.

Have just tried --with-llvm-shared-libs but get the same segfault.

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > 
> > > > The problem on my gentoo system was that I had removed --enable-shared from
> > > > my llvm configure script a few days ago, so I was still linking with an
> > > > older LLVM.
> > > > 
> > > > Can you check that you are passing --enable-shared when configuring LLVM?
> > > 
> > > I wasn't, but passing it does not prevent the segfault - will look into
> > > libelf.
> > 
> > Is it the same segfault?  If the problem is libelf you will see a segfault
> > in radeon_llvm_emit.cpp.  Are building mesa with --enable-opencl or
> > --with-llvm-shared-libs ?
> 
> It is the same segfault as comment1.
> 
> I was building mesa with neither option.
> 
> Have just tried --with-llvm-shared-libs but get the same segfault.

Just tried with the two elf patches you posted to the list and the segfault is fixed.

(In reply to comment #9)
> On the 64 bit build I have only recently installed as it [libelf] became
> required for llvm - I used the source from debian sid.

For the record, that's ambiguous, as Debian has both variants as libelfg0{,-dev} and libelf{1,-dev} respectively.

(In reply to comment #13)
> (In reply to comment #9)
> > On the 64 bit build I have only recently installed as it [libelf] became
> > required for llvm - I used the source from debian sid.
> 
> For the record, that's ambiguous, as Debian has both variants as
> libelfg0{,-dev} and libelf{1,-dev} respectively.

Ahh I guess I got the wrong one :-)

To be more specific I just used the the orig from below, then tried with the diff applied after you mentioned libelf could br the problem

http://packages.debian.org/source/sid/libelf

Working with current gits now the patches are in.