NetBSD Problem Report #50866
From martin@aprisoft.de Mon Feb 29 08:05:46 2016
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 13AD97ACA5
for <gnats-bugs@gnats.NetBSD.org>; Mon, 29 Feb 2016 08:05:46 +0000 (UTC)
Message-Id: <20160229080507.28AF5ED0E4F@emmas.aprisoft.de>
Date: Mon, 29 Feb 2016 09:05:07 +0100 (CET)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: starting firefox crashes the X server
X-Send-Pr-Version: 3.95
>Number: 50866
>Category: toolchain
>Synopsis: starting firefox crashes the X server
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: toolchain-manager
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Feb 29 08:10:00 +0000 2016
>Closed-Date: Mon May 09 23:03:24 +0000 2022
>Last-Modified: Mon May 09 23:03:24 +0000 2022
>Originator: Martin Husemann
>Release: NetBSD 7.99.26
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD whoever-brings-the-night.aprisoft.de 7.99.26 NetBSD 7.99.26 (WHOEVER) #102: Sun Feb 28 20:27:59 CET 2016 martin@seven-days-to-the-wolves.aprisoft.de:/ssd/src/sys/arch/sparc64/compile/WHOEVER sparc64
Architecture: sparc64
Machine: sparc64
>Description:
Starting firefox crashes the X server with a corrupted backtrace:
Program received signal SIGSEGV, Segmentation fault.
__clzdi2 (a=33)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:23
23 {
(gdb) bt
#0 __clzdi2 (a=33)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:23
#1 0xfffffffff661fb64 in __clzdi2 (a=<optimized out>)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:27
(gdb) x/16i __clzdi2
=> 0xfffffffff661fb40 <__clzdi2>: save %sp, -176, %sp
0xfffffffff661fb44 <__clzdi2+4>: srax %i0, 0x20, %g1
0xfffffffff661fb48 <__clzdi2+8>: cmp %g0, %g1
0xfffffffff661fb4c <__clzdi2+12>: addc %g0, -1, %i5
0xfffffffff661fb50 <__clzdi2+16>: and %i5, %i0, %i0
0xfffffffff661fb54 <__clzdi2+20>: and %i5, 0x20, %i5
0xfffffffff661fb58 <__clzdi2+24>: or %i0, %g1, %o0
0xfffffffff661fb5c <__clzdi2+28>: call 0xfffffffff679d980 <__clzdi2@plt>
0xfffffffff661fb60 <__clzdi2+32>: srl %o0, 0, %o0
0xfffffffff661fb64 <__clzdi2+36>: srl %o0, 0, %o0
0xfffffffff661fb68 <__clzdi2+40>: add %o0, -32, %i0
0xfffffffff661fb6c <__clzdi2+44>: add %i5, %i0, %i0
0xfffffffff661fb70 <__clzdi2+48>: rett %i7 + 8
0xfffffffff661fb74 <__clzdi2+52>: sra %o0, 0, %o0
0xfffffffff661fb78: nop
0xfffffffff661fb7c: nop
g0 0x0 0
g1 0xfffffffff661fb40 -161350848
g2 0x82187f40 2182643520
g3 0x26781 157569
g4 0xffffffffffffffff -1
g5 0xffffffff00000004 -4294967292
g6 0x0 0
g7 0xfffffffff7ff4040 -134266816
o0 0x21 33
o1 0x0 0
o2 0x0 0
o3 0x0 0
o4 0x0 0
o5 0x20 32
sp 0xffffffffffdfd3b1 0xffffffffffdfd3b1
o7 0xfffffffff661fb5c -161350820
l0 0x0 0
l1 0x0 0
l2 0x0 0
l3 0x0 0
l4 0x0 0
l5 0x0 0
l6 0x0 0
l7 0x0 0
i0 0x0 0
i1 0x0 0
i2 0x0 0
i3 0x0 0
i4 0x0 0
i5 0x0 0
fp 0x0 0x0
i7 0x0 0
pc 0xfffffffff661fb40 0xfffffffff661fb40 <__clzdi2>
npc 0xfffffffff661fb44 0xfffffffff661fb44 <__clzdi2+4>
state 0x4400008207 292057809415
fsr 0x100000820 [ NXC #11 #32 ]
fprs <unavailable>
y 0x0 0
cwp 0x7 7
pstate 0x82 [ IE #7 ]
asi 0x0 0
ccr 0x44 68
>How-To-Repeat:
s/a
>Fix:
n/a
>Release-Note:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Mon, 29 Feb 2016 20:36:31 +0100
This only happens with binutils 2.26.
Martin
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: christos@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Thu, 3 Mar 2016 08:51:12 +0100
So there are (at least) two bugs involved in this. I filed PR lib/50887
about the other one (libc's _clzdi2 is broken when compiled
with gcc [at least on sparc64]), the other bug is about picking the
libc version of _clzdi2 over the libgcc* version - this is a difference
between binutils 2.23 and 2.26.
Here is a gdb session with the X server before crashing it:
(gdb) break __clzdi2
Breakpoint 1 at 0xffffffffee00e400: __clzdi2. (2 locations)
(gdb) break __clzsi2
Breakpoint 2 at 0xfffffffff6620240: file /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzsi2.c, line 25.
(gdb) break __clz
Function "__clz" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) break __clzti2
Breakpoint 3 at 0xffffffffee00e360: __clzti2. (2 locations)
Note the single location in libc for __clzsi2, but two locations (libgcc
and libc) for the other two.
Now making it crash:
Breakpoint 1, __clzdi2 (a=33)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:23
23 {
(gdb) bt
#0 __clzdi2 (a=33)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:23
#1 0xffffffffeeca4a78 in util_logbase2 (n=<optimized out>)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/auxiliary/util/u_math.h:665
#2 softpipe_create_sampler_view (pipe=0xffffffffeda76000,
resource=0xffffffffeda397a0, templ=0xffffffffffffb110)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/drivers/softpipe/sp_tex_sample.c:3193
#3 0xffffffffeef01308 in aaline_create_texture (aaline=0xffffffffe7287400)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/auxiliary/draw/draw_pipe_aaline.c:429
#4 draw_install_aaline_stage (draw=0xffffffffe7388000,
pipe=pipe@entry=0xffffffffeda76000)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/auxiliary/draw/draw_pipe_aaline.c:1008
#5 0xffffffffeecb372c in softpipe_create_context (screen=0xfffffffff4f902c0,
priv=<optimized out>)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/drivers/softpipe/sp_context.c:298
#6 0xffffffffeea9be20 in st_api_create_context (stapi=<optimized out>,
smapi=0xfffffffff4f70530, attribs=0xffffffffffffb43c,
error=0xffffffffffffb438, shared_stctxi=0x0)
at /ssd/xsrc/external/mit/MesaLib/dist/src/mesa/state_tracker/st_manager.c:658
#7 0xffffffffeec8a578 in dri_create_context (api=<optimized out>,
visual=0xfffffffff4f71d40, cPriv=0xffffffffedb854c0,
major_version=<optimized out>, minor_version=<optimized out>,
flags=<optimized out>, notify_reset=false, error=0xffffffffffffb60c,
sharedContextPrivate=0x0)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/state_trackers/dri/dri_context.c:112
#8 0xffffffffee9c74b8 in driCreateContextAttribs (
screen=screen@entry=0xfffffffff4f70480, api=api@entry=0,
config=config@entry=0xfffffffff4f71d40, shared=shared@entry=0x0,
num_attribs=num_attribs@entry=0, attribs=attribs@entry=0x0,
error=0xffffffffffffb60c, data=0xfffffffff4f21100)
at /ssd/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/common/dri_util.c:435
#9 0xffffffffee9c758c in driCreateNewContextForAPI (data=0xfffffffff4f21100,
shared=0x0, config=0xfffffffff4f71d40, api=0, screen=0xfffffffff4f70480)
at /ssd/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/common/dri_util.c:464
#10 driCreateNewContext (screen=0xfffffffff4f70480, config=0xfffffffff4f71d40,
shared=0x0, data=0xfffffffff4f21100)
at /ssd/xsrc/external/mit/MesaLib/dist/src/mesa/drivers/dri/common/dri_util.c:472
#11 0x000000000029cdb8 in __glXDRIscreenCreateContext (
baseScreen=0xfffffffff4f20660, glxConfig=0xfffffffff4f4bd00,
baseShareContext=0x0)
at /ssd/xsrc/external/mit/xorg-server/dist/glx/glxdriswrast.c:296
#12 0x00000000002a07e4 in DoCreateContext (gcId=<optimized out>,
shareList=<optimized out>, config=0xfffffffff4f4bd00,
pGlxScreen=0xfffffffff4f20660, isDirect=0 '\000', cl=0xffffffffedb8d928)
at /ssd/xsrc/external/mit/xorg-server/dist/glx/glxcmds.c:276
#13 0x00000000002a12e0 in __glXDisp_CreateContext (cl=0xffffffffedb8d928,
pc=0xfffffffff4f08038 "\233\003")
at /ssd/xsrc/external/mit/xorg-server/dist/glx/glxcmds.c:330
#14 0x000000000029d794 in __glXDispatch (client=0xffffffffedb8d800)
at /ssd/xsrc/external/mit/xorg-server/dist/glx/glxext.c:558
#15 0x0000000000161af0 in Dispatch ()
#16 0x00000000002f3f90 in main ()
And indeed, continuing leads to direct recursion:
#0 __clzdi2 (a=33)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:23
#1 0xfffffffff661fb64 in __clzdi2 (a=<optimized out>)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:27
#2 0xfffffffff661fb64 in __clzdi2 (a=<optimized out>)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:27
#3 0xfffffffff661fb64 in __clzdi2 (a=<optimized out>)
at /ssd/src/sys/external/bsd/compiler_rt/dist/lib/builtins/clzdi2.c:27
#4 0xffffffffeeca4a78 in util_logbase2 (n=<optimized out>)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/auxiliary/util/u_math.h:665
#5 softpipe_create_sampler_view (pipe=0xffffffffeda76000,
resource=0xffffffffeda397a0, templ=0xffffffffffffb110)
at /ssd/xsrc/external/mit/MesaLib/dist/src/gallium/drivers/softpipe/sp_tex_sample.c:3193
(but the recursion is part of the other bug).
The question here is: what does binutils 2.26 different to causes libc's
version of _clzdi2 to be called in the above stack trace.
I can not spot anything obvious: both version of the
usr/X11R7/lib/modules/dri/*.so files have
0000000000000000 F *UND* 0000000000000000 __clzdi2@@GCC_3.4
as reference to the function and
Dynamic Section:
NEEDED libdrm.so.3
NEEDED libdrm_radeon.so.0
NEEDED libglapi.so.0
NEEDED libexpat.so.2
NEEDED libstdc++.so.7
NEEDED libm.so.0
NEEDED libgcc_s.so.1
NEEDED libc.so.12
as dependencies. Something about the symbol version? How would I dump version
details?
Martin
From: christos@zoulas.com (Christos Zoulas)
To: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org
Cc: joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Thu, 3 Mar 2016 11:35:00 -0500
On Mar 3, 8:51am, martin@duskware.de (Martin Husemann) wrote:
-- Subject: Re: toolchain/50866: starting firefox crashes the X server
| Something about the symbol version? How would I dump version details?
[11:31am] 4065>/usr/obj/x86_64/tools/bin/sparc64--netbsd-readelf -s libgcc_s.so | grep clz
121: 000000000000e360 136 FUNC GLOBAL DEFAULT 9 __clzti2@@GCC_3.4
131: 000000000000e400 116 FUNC GLOBAL DEFAULT 9 __clzdi2@@GCC_3.4
16: 000000000000f398 256 OBJECT LOCAL DEFAULT 11 __clz_tab
163: 000000000000e360 136 FUNC GLOBAL DEFAULT 9 __clzti2
173: 000000000000e400 116 FUNC GLOBAL DEFAULT 9 __clzdi2
[11:32am] 4066>/usr/obj/x86_64/tools/bin/sparc64--netbsd-readelf -s /usr/src/lib/libc/obj.sparc64/libc.so | grep clz
701: 000000000011fb80 56 FUNC GLOBAL DEFAULT 7 __clzdi2
1169: 0000000000120280 176 FUNC GLOBAL DEFAULT 7 __clzsi2
2840: 0000000000123340 52 FUNC GLOBAL DEFAULT 7 __clzti2
796: 000000000011fb80 56 FUNC GLOBAL DEFAULT 7 __clzdi2
1264: 0000000000120280 176 FUNC GLOBAL DEFAULT 7 __clzsi2
2935: 0000000000123340 52 FUNC GLOBAL DEFAULT 7 __clzti2
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/symversion.html
looks like it finds the libc symbol first now...
christos
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Thu, 3 Mar 2016 19:41:26 +0100
On Thu, Mar 03, 2016 at 11:35:00AM -0500, Christos Zoulas wrote:
> looks like it finds the libc symbol first now...
But we did not change ld.elf_so and I can't spot any relevant
difference in the binaries.
Let me check if replacing the ld.elf_so binary fixes it...
Martin
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Fri, 4 Mar 2016 10:33:25 +0100
On Thu, Mar 03, 2016 at 07:41:26PM +0100, Martin Husemann wrote:
> Let me check if replacing the ld.elf_so binary fixes it...
No, it doesn't - there must be a difference in some other binary.
Martin
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Wed, 9 Mar 2016 12:08:53 +0100
So the differenc is:
with new binutils, the only thing under usr/X11R7/lib that gets a libgcc_s
NEEDED entry is:
modules/dri/gallium_dri.so.0
while with old binutils the list is quite lengthy:
libFS.so.7.0
libGLw.so.2.0
X11/locale/lib/common/ximcp.so.2.0
X11/locale/lib/common/xlcDef.so.2.0
X11/locale/lib/common/xlcUTF8Load.so.2.0
X11/locale/lib/common/xlibi18n.so.2.0
X11/locale/lib/common/xomGeneric.so.2.0
libICE.so.7.0
libSM.so.7.0
libX11-xcb.so.1.0
libX11.so.7.0
libXRes.so.2.0
libXTrap.so.7.0
libXau.so.7.0
libXaw6.so.7.0
libXaw7.so.10.0
libXcomposite.so.2.0
libXcursor.so.2.0
libXdamage.so.2.0
libXdmGreet.so.0.0
libXdmcp.so.7.0
libXevie.so.2.0
libXext.so.7.1
libXfixes.so.4.0
libXfont.so.3.0
libXfontcache.so.2.0
libXft.so.3.0
libXi.so.7.1
libXinerama.so.2.0
libXmu.so.7.0
libXmuu.so.2.0
libXpm.so.5.0
libXpresent.so.1.0
libXrandr.so.3.2
libXrender.so.2.0
libXss.so.2.0
libXt.so.7.0
libXtst.so.7.0
libXv.so.2.0
libXvMC.so.2.0
libXvMCW.so.1.0
libXxf86dga.so.2.0
libXxf86misc.so.2.0
libXxf86vm.so.2.0
libdrm.so.3.3
libdrm_radeon.so.0.0
libfontconfig.so.2.2
libfontenc.so.2.0
libfreetype.so.18.0.12
libgbm.so.1.0
libxcb-glx.so.0.1
libpciaccess.so.0.3
libxcb-composite.so.0.1
libpixman-1.so.2.2
libxcb-atom.so.1.0
libxcb-aux.so.0.0
libxcb-damage.so.0.1
libxcb-dpms.so.0.1
libxcb-dri2.so.0.1
libxcb-dri3.so.0.1
libxcb-randr.so.1.0
libxcb-event.so.1.0
libxcb-icccm.so.1.0
libxcb-image.so.0.0
libxcb-keysyms.so.1.0
libxcb-present.so.0.1
modules/dri/gallium_dri.so.0
modules/drivers/ag10e_drv.so.0
modules/drivers/ati_drv.so.6
modules/drivers/glint_drv.so.1
modules/drivers/kbd_drv.so.1
modules/drivers/mach64_drv.so.6
modules/drivers/mga_drv.so.1
modules/drivers/mouse_drv.so.1
modules/drivers/r128_drv.so.6
modules/drivers/radeon_drv.so.6
modules/drivers/suncg6_drv.so.1
modules/drivers/sunffb_drv.so.1
modules/drivers/sunleo_drv.so.1
modules/drivers/ws_drv.so.1
modules/drivers/wsfb_drv.so.0
modules/extensions/libdbe.so.0
modules/extensions/libdri.so.0
modules/extensions/libdri2.so.0
modules/extensions/libextmod.so.0
modules/extensions/libglx.so.0
modules/extensions/librecord.so.0
modules/extensions/libshadow.so.0
modules/libexa.so.0
modules/libfb.so.0
modules/libshadowfb.so.0
modules/libvbe.so.0
modules/libvgahw.so.0
modules/libxaa.so.0
libxcb-property.so.1.0
libxcb-record.so.0.1
libxcb-render-util.so.0.0
libxcb-render.so.0.1
libxcb-screensaver.so.0.1
libxcb-reply.so.1.0
libxcb-res.so.0.1
libxcb-shape.so.0.1
libxcb-shm.so.0.1
libxcb-xfixes.so.0.1
libxcb-sync.so.1.0
libxcb-xevie.so.0.1
libxcb-xf86dri.so.0.1
libxcb-xinerama.so.0.1
libxcb-xkb.so.1.0
libxcb-xtest.so.0.1
libxcb-xv.so.0.1
libxkbfile.so.2.0
libxcb-xvmc.so.0.1
libxcb.so.2.0
libxkbui.so.2.0
This used to cause libgcc_s.so to be loaded quite early in the X server,
and be searched earlier when resolving __clzdi2.
Now is this a bug in old or new binutils?
Martin
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Wed, 9 Mar 2016 13:47:06 +0100
On Wed, Mar 09, 2016 at 12:08:53PM +0100, Martin Husemann wrote:
> So the differenc is:
>
> with new binutils, the only thing under usr/X11R7/lib that gets a libgcc_s
> NEEDED entry is:
>
> modules/dri/gallium_dri.so.0
Looking at symbol references, the new behaviour seems to be correct.
Martin
From: christos@zoulas.com (Christos Zoulas)
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Wed, 9 Mar 2016 09:02:04 -0500
On Mar 9, 12:08pm, martin@duskware.de (Martin Husemann) wrote:
-- Subject: Re: toolchain/50866: starting firefox crashes the X server
| So the differenc is:
|
| with new binutils, the only thing under usr/X11R7/lib that gets a libgcc_s
| NEEDED entry is:
|
| modules/dri/gallium_dri.so.0
|
| while with old binutils the list is quite lengthy:
|
| libFS.so.7.0
| libGLw.so.2.0
| X11/locale/lib/common/ximcp.so.2.0
| X11/locale/lib/common/xlcDef.so.2.0
| X11/locale/lib/common/xlcUTF8Load.so.2.0
| X11/locale/lib/common/xlibi18n.so.2.0
| X11/locale/lib/common/xomGeneric.so.2.0
| libICE.so.7.0
| libSM.so.7.0
| libX11-xcb.so.1.0
| libX11.so.7.0
| libXRes.so.2.0
| libXTrap.so.7.0
| libXau.so.7.0
| libXaw6.so.7.0
| libXaw7.so.10.0
| libXcomposite.so.2.0
| libXcursor.so.2.0
| libXdamage.so.2.0
| libXdmGreet.so.0.0
| libXdmcp.so.7.0
| libXevie.so.2.0
| libXext.so.7.1
| libXfixes.so.4.0
| libXfont.so.3.0
| libXfontcache.so.2.0
| libXft.so.3.0
| libXi.so.7.1
| libXinerama.so.2.0
| libXmu.so.7.0
| libXmuu.so.2.0
| libXpm.so.5.0
| libXpresent.so.1.0
| libXrandr.so.3.2
| libXrender.so.2.0
| libXss.so.2.0
| libXt.so.7.0
| libXtst.so.7.0
| libXv.so.2.0
| libXvMC.so.2.0
| libXvMCW.so.1.0
| libXxf86dga.so.2.0
| libXxf86misc.so.2.0
| libXxf86vm.so.2.0
| libdrm.so.3.3
| libdrm_radeon.so.0.0
| libfontconfig.so.2.2
| libfontenc.so.2.0
| libfreetype.so.18.0.12
| libgbm.so.1.0
| libxcb-glx.so.0.1
| libpciaccess.so.0.3
| libxcb-composite.so.0.1
| libpixman-1.so.2.2
| libxcb-atom.so.1.0
| libxcb-aux.so.0.0
| libxcb-damage.so.0.1
| libxcb-dpms.so.0.1
| libxcb-dri2.so.0.1
| libxcb-dri3.so.0.1
| libxcb-randr.so.1.0
| libxcb-event.so.1.0
| libxcb-icccm.so.1.0
| libxcb-image.so.0.0
| libxcb-keysyms.so.1.0
| libxcb-present.so.0.1
| modules/dri/gallium_dri.so.0
| modules/drivers/ag10e_drv.so.0
| modules/drivers/ati_drv.so.6
| modules/drivers/glint_drv.so.1
| modules/drivers/kbd_drv.so.1
| modules/drivers/mach64_drv.so.6
| modules/drivers/mga_drv.so.1
| modules/drivers/mouse_drv.so.1
| modules/drivers/r128_drv.so.6
| modules/drivers/radeon_drv.so.6
| modules/drivers/suncg6_drv.so.1
| modules/drivers/sunffb_drv.so.1
| modules/drivers/sunleo_drv.so.1
| modules/drivers/ws_drv.so.1
| modules/drivers/wsfb_drv.so.0
| modules/extensions/libdbe.so.0
| modules/extensions/libdri.so.0
| modules/extensions/libdri2.so.0
| modules/extensions/libextmod.so.0
| modules/extensions/libglx.so.0
| modules/extensions/librecord.so.0
| modules/extensions/libshadow.so.0
| modules/libexa.so.0
| modules/libfb.so.0
| modules/libshadowfb.so.0
| modules/libvbe.so.0
| modules/libvgahw.so.0
| modules/libxaa.so.0
| libxcb-property.so.1.0
| libxcb-record.so.0.1
| libxcb-render-util.so.0.0
| libxcb-render.so.0.1
| libxcb-screensaver.so.0.1
| libxcb-reply.so.1.0
| libxcb-res.so.0.1
| libxcb-shape.so.0.1
| libxcb-shm.so.0.1
| libxcb-xfixes.so.0.1
| libxcb-sync.so.1.0
| libxcb-xevie.so.0.1
| libxcb-xf86dri.so.0.1
| libxcb-xinerama.so.0.1
| libxcb-xkb.so.1.0
| libxcb-xtest.so.0.1
| libxcb-xv.so.0.1
| libxkbfile.so.2.0
| libxcb-xvmc.so.0.1
| libxcb.so.2.0
| libxkbui.so.2.0
|
|
| This used to cause libgcc_s.so to be loaded quite early in the X server,
| and be searched earlier when resolving __clzdi2.
|
| Now is this a bug in old or new binutils?
What is different in the way we build gallium?
christos
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Wed, 9 Mar 2016 15:03:46 +0100
On Wed, Mar 09, 2016 at 09:02:04AM -0500, Christos Zoulas wrote:
> What is different in the way we build gallium?
Nothing, it just generates calls to __clzdi2 (and one other support
function).
Looks to me like all works as intended (now) and the old version was buggy.
Martin
From: christos@zoulas.com (Christos Zoulas)
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org, joerg@NetBSD.org
Subject: Re: toolchain/50866: starting firefox crashes the X server
Date: Wed, 9 Mar 2016 09:05:02 -0500
On Mar 9, 3:03pm, martin@duskware.de (Martin Husemann) wrote:
-- Subject: Re: toolchain/50866: starting firefox crashes the X server
| On Wed, Mar 09, 2016 at 09:02:04AM -0500, Christos Zoulas wrote:
| > What is different in the way we build gallium?
|
| Nothing, it just generates calls to __clzdi2 (and one other support
| function).
|
| Looks to me like all works as intended (now) and the old version was buggy.
Perhaps the old version was not doing --as-needed?
christos
State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sat, 22 Sep 2018 14:32:52 +0000
State-Changed-Why:
what's the status of this? (it sounds like it's fixed)
State-Changed-From-To: feedback->closed
State-Changed-By: rillig@NetBSD.org
State-Changed-When: Mon, 09 May 2022 23:03:24 +0000
State-Changed-Why:
Feedback timeout.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home