Bug#1042018: qt6-declarative: FTBFS on hppa - Segmentation fault in /usr/lib/qt6/bin/qsb

[John David Anglin]

Source: qt6-declarative
Version: 6.4.2+dfsg-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Build fails here:
[22/6600] cd /<>/obj-hppa-linux-gnu/src/quick && 
/usr/lib/qt6/bin/qsb --glsl 100es,120,150 --hlsl 50 --msl 12 -b -O -s -o 
/<>/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 /<>/src/quick/scenegraph/shaders_ng/24bittextmask.frag
FAILED: src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb 
/<>/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 
cd /<>/obj-hppa-linux-gnu/src/quick && /usr/lib/qt6/bin/qsb --glsl 
100es,120,150 --hlsl 50 --msl 12 -b -O -s -o 
/<>/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 /<>/src/quick/scenegraph/shaders_ng/24bittextmask.frag
Segmentation fault (core dumped)

See:
https://buildd.debian.org/status/fetch.php?pkg=qt6-declarative=hppa=6.4.2%2Bdfsg-3=1690289443=0

dave@mx3210:~/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/obj-hppa-linux-g
nu/src/quick$ gdb /usr/lib/qt6/bin/qsb
GNU gdb (Debian 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "hppa-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/qt6/bin/qsb...
Reading symbols from 
/usr/lib/debug/.build-id/2d/3c434ee4acf266d2dc6fd1ff1289e07e4fd07c.debug...
(gdb) set args --glsl 100es,120,150 --hlsl 50 --msl 12 -b -O -s -o 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/src/quick/scenegraph/shaders_ng/24bittextmask.frag
(gdb) r
Starting program: /usr/lib/qt6/bin/qsb --glsl 100es,120,150 --hlsl 50 --msl 12 
-b -O -s -o 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/obj-hppa-linux-gnu/src/quick/.qsb/scenegraph/shaders_ng/24bittextmask.frag.qsb
 
/home/dave/debian/qt6-declarative/qt6-declarative-6.4.2+dfsg/src/quick/scenegraph/shaders_ng/24bittextmask.frag
warning: Unable to find libthread_db matching inferior's thread library, thread 
debugging will not be available.
[Detaching after vfork from child process 24823]

Program received signal SIGSEGV, Segmentation fault.
0xf8af656c in vforkfd (flags=1,
childFn=0xf8aec7d4 
, token=0xf8f02888, ppid=0xf8f028f0)
at ./src/corelib/io/../../3rdparty/forkfd/forkfd.c:815
815 ./src/corelib/io/../../3rdparty/forkfd/forkfd.c: No such file or 
directory.
(gdb) bt
#0  0xf8af656c in vforkfd (flags=1,
childFn=0xf8aec7d4 
, token=0xf8f02888, ppid=0xf8f028f0)
at ./src/corelib/io/../../3rdparty/forkfd/forkfd.c:815
#1  QProcessPrivate::startProcess (this=0x91c80)
at ./src/corelib/io/qprocess_unix.cpp:472
#2  QProcessPrivate::start (this=0x91c80, mode=...)
at ./src/corelib/io/qprocess.cpp:2163
#3  0x0001bc20 in runProcess (binary=..., arguments=..., output=0xf8f02888,
errorOutput=0x5112) at /usr/include/hppa-linux-gnu/qt6/QtCore/qflags.h:74
#4  0x00016884 in main (argc=, argv=)
at ./tools/qsb/qsb.cpp:661
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0xf8af655c to 0xf8af657c:
   0xf8af655c 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+708>:  
  copy r21,r26
   0xf8af6560 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+712>:  
  b,l 0xf8ad428c,rp
   0xf8af6564 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+716>:  
  stw r21,-c4(sp)
   0xf8af6568 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+720>:  
  copy r4,r19
=> 0xf8af656c 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+724>:  
  ldw 0(r8),r20
   0xf8af6570 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+728>:  
  cmpib,<> 0,r20,0xf8af6aa0 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+2056>
   0xf8af6574 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+732>:  
  copy ret0,r3
   0xf8af6578 
<_ZN15QProcessPrivate5startE6QFlagsIN13QIODeviceBase12OpenModeFlagEE+736>:  
  addil L%d000,r19,r1
End of assembler dump.
(gdb) p/x $r8
$1 = 0x5112

r8 is misaligned for ldw instruction but this didn't cause fault.

(gdb) x/x 0x5110
0x5110: Cannot access memory at address 0x5110

Regards,
Dave Anglin

-- System Information:
Debian 

Bug#1021404: qt6-base: FTBFS on hppa - Unknown Q_PROCESSOR_xxx macro

[John David Anglin]

Source: qt6-base
Version: 6.3.1+dfsg-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

The build fails here:

[357/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/text/qregularexpression.cpp.o -c 
/<>/src/corelib/text/qregularexpression.cpp
[358/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 -MD -MT src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -MF 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o.d -o 
src/corelib/CMakeFiles/Core.dir/io/qfilesystemwatcher.cpp.o -c 
/<>/src/corelib/io/qfilesystemwatcher.cpp
[359/1566] /usr/bin/c++ -DBACKTRACE_HEADER=\"execinfo.h\" -DCore_EXPORTS 
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT 
-DQT_BUILD_CORE_LIB -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 -DQT_DISABLE_DEPRECATED_BEFORE=0x05 
-DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_NO_USING_NAMESPACE -DQT_TYPESAFE_FLAGS -DQT_USE_QSTRINGBUILDER 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
-I/<>/obj-hppa-linux-gnu/src/corelib/Core_autogen/include 
-I/<>/obj-hppa-linux-gnu/include 
-I/<>/obj-hppa-linux-gnu/include/QtCore 
-I/<>/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib 
-I/<>/obj-hppa-linux-gnu/src/corelib/global 
-I/<>/obj-hppa-linux-gnu/src/corelib/kernel 
-I/<>/src/corelib/../3rdparty/tinycbor/src 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1 
-I/<>/obj-hppa-linux-gnu/include/QtCore/6.3.1/QtCore 
-I/<>/src/corelib/../3rdparty/forkfd 
-I/<>/mkspecs/linux-g++ -isystem /usr/include/double-conversion 
-isystem /usr/include/glib-2.0 -isystem 
/usr/lib/hppa-linux-gnu/glib-2.0/include -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden 
-fvisibility-inlines-hidden -Wall -Wextra -Wsuggest-override -std=c++17 
-Winvalid-pch -include 
/<>/obj-hppa-linux-gnu/src/corelib/CMakeFiles/Core.dir/cmake_pch.hxx
 

Bug#1021312: qtquickcontrols-opensource-src: FTBFS on hppa - Tests_TreeView::test_pressAndHold

[John David Anglin]

Source: qtquickcontrols-opensource-src
Version: 5.15.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Testsuite fails with following error:

PASS   : qtquickcontrols::Tests_TreeView::test_keys_navigation()
FAIL!  : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values 
are not the same
   Actual   (): 0
   Expected (): 1
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_contiguousSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_extendedSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_multiSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_noSelection()
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(402)]
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(404)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_singleSelection()
PASS   : qtquickcontrols::Tests_TreeView::cleanupTestCase()
Totals: 498 passed, 1 failed, 6 skipped, 0 blacklisted, 410752ms
* Finished testing of qtquickcontrols *
make[5]: *** [Makefile:318: check] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.6-2=1664978713=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[John David Anglin]

Source: libsdl2
Version: 2.24.0+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Build fails in testsuite:

Thinkpad USB keyboard with Trackpoint - Trackpoint...
Expected 0x0003
MOUSE
KEYBOARD
Got  0x
No information...
OK
testevdev: FAILED: 1
testfilesystem...
INFO: base path: '/<>/debian/build-tests/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/libsdl/test_filesystem/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/test_filesystem/'
testfilesystem: OK
...
testdisplayinfo: OK
make[2]: *** [Makefile:416: check] Error 1
make[2]: Leaving directory '/<>/debian/build-tests'
dh_auto_test: error: cd debian/build-tests && make -j4 check 
"TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 V=1 returned exit code 2
make[1]: *** [debian/rules:142: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:81: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libsdl2=hppa=2.24.1%2Bdfsg-1=1664977752=0

Similar fail occurs on powerpc.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1016519: ffmpeg: Still FTBFS on hppa and powerpc

[John David Anglin]

Source: ffmpeg
Followup-For: Bug #1016519

Dear Maintainer,

This is with version 7:5.1-3:
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=hppa=7%3A5.1-3=1661576231=0

/<>/tests/fate-run.sh fate-filter-overlay_yuv422 "" "" 
"/<>/debian/standard" 'framecrc -auto_conversion_filters -c:v 
pgmyuv -i /<>/debian/standard/tests/vsynth1/%02d.pgm 
-filter_complex_script 
/<>/debian/standard/tests/data/filtergraphs/overlay_yuv422' '' '' 
'' '1' '' '' '' '' '' '' '' '' '' ''
 /<>/debian/standard/ffmpeg -nostdin -nostats 
-noauto_conversion_filters -cpuflags all -auto_conversion_filters -c:v pgmyuv 
-hwaccel none -threads 1 -thread_type frame+slice -i 
/<>/debian/standard/tests/vsynth1/%02d.pgm -filter_complex_script 
/<>/debian/standard/tests/data/filtergraphs/overlay_yuv422 
-bitexact -f framecrc -
--- /<>/tests/ref/fate/filter-overlay_yuv420p102022-07-22 
17:58:40.0 +
+++ tests/data/fate/filter-overlay_yuv420p102022-08-27 04:23:18.426707238 
+
@@ -3,6 +3,6 @@
 #codec_id 0: rawvideo
 #dimensions 0: 352x288
 #sar 0: 0/1
-0,  0,  0,1,   304128, 0x524bcfc6
-0,  1,  1,1,   304128, 0xab3a13af
-0,  2,  2,1,   304128, 0xac08d718
+0,  0,  0,1,   304128, 0xd041d116
+0,  1,  1,1,   304128, 0x293f14ff
+0,  2,  2,1,   304128, 0x2a0dd868
Test filter-overlay_yuv420p10 failed. Look at 
tests/data/fate/filter-overlay_yuv420p10.err for details.
ffmpeg version 5.1-3 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-1)
  configuration: --prefix=/usr --extra-version=3 --toolchain=hardened 
--libdir=/usr/lib/hppa-linux-gnu --incdir=/usr/include/hppa-linux-gnu 
--arch=hppa --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa 
--enable-libaom --enable-libass --enable-libbluray --enable-libbs2b 
--enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d 
--enable-libflite --enable-libfontconfig --enable-libfreetype 
--enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm 
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq 
--enable-librist --enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh 
--enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab 
--enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 
--enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq 
--enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl 
--enable-opengl --enable-sdl2 --disable-sndio --enable-libdc1394 
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r 
--enable-libx264 --enable-libplacebo --enable-shared
  libavutil  57. 28.100 / 57. 28.100
  libavcodec 59. 37.100 / 59. 37.100
  libavformat59. 27.100 / 59. 27.100
  libavdevice59.  7.100 / 59.  7.100
  libavfilter 8. 44.100 /  8. 44.100
  libswscale  6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc56.  6.100 / 56.  6.100
Input #0, image2, from 
'/<>/debian/standard/tests/vsynth1/%02d.pgm':
  Duration: 00:00:02.00, start: 0.00, bitrate: N/A
  Stream #0:0: Video: pgmyuv, yuv420p, 352x288, 25 fps, 25 tbr, 25 tbn
Stream mapping:
  Stream #0:0 (pgmyuv) -> split:default
  overlay:default -> Stream #0:0 (rawvideo)
Output #0, framecrc, to 'pipe:':
  Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(tv, 
progressive), 352x288, q=2-31, 38016 kb/s, 25 fps, 25 tbn
Metadata:
  encoder : Lavc rawvideo
frame=3 fps=1.2 q=-0.0 Lsize=   0kB time=00:00:00.12 bitrate=  
17.6kbits/s speed=0.0462x
video:891kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
make[2]: *** [/<>/tests/Makefile:305: 
fate-filter-overlay_yuv420p10] Error 1

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
merged-usr: no
Architecture: hppa (parisc64)

Kernel: Linux 5.19.5+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#984401: vtk7: ftbfs with GCC-11

[John David Anglin]

Source: vtk7
Version: 7.1.1+dfsg2-10+b2
Followup-For: Bug #984401

Dear Maintainer,

On hppa:

[  3%] Building CXX object 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o
cd /<>/debian/build/ThirdParty/xdmf2/vtkxdmf2/libsrc && 
/usr/bin/mpic++ -DLinux -DMPICH_IGNORE_CXX_SEEK -DVTK_IN_VTK -D_HPUX_SOURCE 
-Dvtkxdmf2_EXPORTS -I/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc 
-I/<>/debian/build/ThirdParty/xdmf2/vtkxdmf2/libsrc 
-I/<>/debian/build/ThirdParty/xdmf2 
-I/<>/ThirdParty/xdmf2 
-I/<>/debian/build/ThirdParty/hdf5 
-I/<>/ThirdParty/hdf5 -I/usr/include/hdf5/openmpi 
-I/<>/debian/build/ThirdParty/zlib 
-I/<>/ThirdParty/zlib 
-I/<>/debian/build/ThirdParty/libxml2 
-I/<>/ThirdParty/libxml2 -I/usr/include/libxml2 
-I/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/utils -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2  -w -w -w -fPIC -MD -MT 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o -MF 
CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o.d -o 
CMakeFiles/vtkxdmf2.dir/XdmfDsmMsg.cxx.o -c 
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmMsg.cxx
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx: In member 
function ‘virtual XdmfInt32 xdmf2::XdmfDsmComm::Receive(xdmf2::XdmfDsmMsg*)’:
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx:55:18: error: 
ordered comparison of pointer with integer zero (‘void*’ and ‘int’)
   55 | if(Msg->Data <= 0 ){
  |~~^~~~
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx: In member 
function ‘virtual XdmfInt32 xdmf2::XdmfDsmComm::Send(xdmf2::XdmfDsmMsg*)’:
/<>/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx:69:18: error: 
ordered comparison of pointer with integer zero (‘void*’ and ‘int’)
   69 | if(Msg->Data <= 0 ){
  |~~^~~~
make[4]: *** 
[ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/build.make:541: 
ThirdParty/xdmf2/vtkxdmf2/libsrc/CMakeFiles/vtkxdmf2.dir/XdmfDsmComm.cxx.o] 
Error 1
make[4]: *** Waiting for unfinished jobs

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.14.12+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#920018: Memory Leak in journald? Failed to write entry (23 items, 500 bytes), ignoring: Cannot allocate memory

[John David Anglin]

I still seeing this bug on hppa with systemd 240-5.  Started with 240-4.

Regards,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#917215: systemd: test-json fails on hppa

[John David Anglin]

This failure also happens on hppa.  It didn't fail in previous version.

Regards,
Dave Anglin

-- 
John David Anglin  dave.ang...@bell.net

Bug#808560: [buildd-tools-devel] Bug#808560: sbuild: Use of uninitialized value $_ in concatenation (.)

[John David Anglin]

On 2015-12-23, at 4:27 AM, Niko Tyni wrote:

> On Tue, Dec 22, 2015 at 09:00:20AM +0200, Niko Tyni wrote:
>> On Tue, Dec 22, 2015 at 07:48:11AM +0100, Johannes Schauer wrote:
> 
>>> If the problem is this change of behaviour as you described it, then the 
>>> fix is
>>> a very simple one:
>> 
>> Cool, thanks! I'm not sure if there are other problems, this was the
>> one I found first.
> 
> I can confirm that sbuild works fine for me again with your patch.

Same here.

Thanks,
--
John David Anglin   dave.ang...@bell.net

Bug#713566: guile-1.6: FTBFS on hppa

[John David Anglin]

Package: guile-1.6
Version: 1.6.8-10.3
Followup-For: Bug #713566

See:
http://buildd.debian-ports.org/status/fetch.php?pkg=guile-1.6arch=hppaver=1.6.8-10.3stamp=1410537790

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.16.3+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762485: geographiclib: FTBFS on hppa: symbols

[John David Anglin]

Package: geographiclib
Version: 1.37-2
Followup-For: Bug #762485

See build log:
http://buildd.debian-ports.org/status/fetch.php?pkg=geographiclibarch=hppaver=1.37-2stamp=1412084220

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.16.3+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730885: Debian BTS Bug #730885

[John David Anglin]

On 29-Sep-14, at 8:19 PM, ferse...@br.ibm.com wrote:


Just thought it might be useful to you as well.


I could see that a similar approach would work for hppa, but I think  
something better is needed to handle

all multiarch systems.

Thanks,
Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754713: elmerfem: FTBFS on s390x: The MPI version needs parpack. Disabling MPI.

[John David Anglin]

Package: elmerfem
Version: 6.1.0.svn.5396.dfsg2-4
Followup-For: Bug #754713

Also fails on hppa in a similar way:
http://buildd.debian-ports.org/status/fetch.php?pkg=elmerfemarch=hppaver=6.1.0.svn.5396.dfsg2-4stamp=1405298469


-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.15.5+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749718: texlive-bin: FTBFS on hppa

[John David Anglin]

On 30-May-14, at 6:03 AM, Hilmar Preusse wrote:


Disable luajit on hppa too?


Testing build with --disable-luajittex.

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749718: FTBFS on s390x

[John David Anglin]

On 30-May-14, at 7:39 PM, Norbert Preining wrote:


On Fri, 30 May 2014, Emilio Pozuelo Monfort wrote:
Thanks! It has been built on s390x, but I'm seeing some problems  
when texlive is

installed, e.g.:


Did you use the package I uploaded? It requires
tex-common = 5.02
and tex-common 5.02 fixes this problem, hopefully!



I'm also seeing a problem during installation of texlive-base:

Setting up texlive-base (2014.20140528-1) ...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
/usr/bin/tl-paper: setting paper size for dvips to letter.
/usr/bin/tl-paper: setting paper size for dvipdfmx to letter.
/usr/bin/tl-paper: setting paper size for xdvi to letter.
/usr/bin/tl-paper: setting paper size for pdftex to letter.
Running mktexlsr. This may take some time... done.
Building format(s) --all.
This may take some time...
fmtutil-sys failed. Output has been stored in
/tmp/fmtutil.q1QfX8tz
Please include this file if you report a bug.

At the end of /tmp/fmtutil.q1QfX8tz, I see:

fmtutil: running `luajittex -ini   -jobname=luajittex - 
progname=luajittex luatex.ini' ...

/usr/bin/fmtutil: 381: /usr/bin/fmtutil: luajittex: not found

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749718: texlive-bin: FTBFS on hppa

[John David Anglin]

Package: texlive-bin
Version: 2014.20140528.34243-1
Followup-For: Bug #749718

See:
http://buildd.debian-ports.org/status/fetch.php?pkg=texlive-binarch=hppaver=2014.20140528.34243-1stamp=1401375185


-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.15.0-rc6+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746020: closed by Jordi Mallach jo...@debian.org (Fixed in upload 2:6.0.0+dfsg-2.3)

[John David Anglin]

Symbol update for hppa was successful.

Thanks,
Dave

--
John David Anglindave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745906: gcc-snapshot: FTBFS on hppa: cp: cannot stat 'debian/gcc-ar.1'

[John David Anglin]

Package: gcc-snapshot
Version: 20140423-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

During install, the following error occurs:

for i in ar nm ranlib; do \
  cp debian/gcc-$i.1 
debian/tmp/usr/lib/gcc-snapshot/share/man/man1/gcc-$i.1; \
done
cp: cannot stat 'debian/gcc-ar.1': No such file or directory
make[1]: *** [stamps/07-install-snap-stamp] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'

Full log is here:
http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-snapshotarch=hppaver=20140423-1stamp=1398489847

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.1+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#746020: gmp: FTBFS on hppa: incorrect symbols

[John David Anglin]

Package: gmp
Version: 2:6.0.0+dfsg-2.2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

See:
http://buildd.debian-ports.org/status/fetch.php?pkg=gmparch=hppaver=2%3A6.0.0%2Bdfsg-2.2stamp=1398560026

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.1+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745683: heimdal: FTBFS on hppa -- check-iprop test fails

[John David Anglin]

On 23-Apr-14, at 9:07 PM, Jelmer Vernooij wrote:


Can you provide the tests/kdc/test-suite.log file from the builder?


It seems the failure is somewhat intermittent.  I had a successful  
build outside buildd last night.
So, it looks like I will need to try grab the log from the chroot  
before it is purged.


Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745683: heimdal: FTBFS on hppa -- check-iprop test fails

[John David Anglin]

On 24-Apr-14, at 8:58 PM, Jelmer Vernooij wrote:


On Thu, Apr 24, 2014 at 08:29:00AM -0400, John David Anglin wrote:

On 23-Apr-14, at 9:07 PM, Jelmer Vernooij wrote:


Can you provide the tests/kdc/test-suite.log file from the builder?


It seems the failure is somewhat intermittent.  I had a successful  
build

outside buildd last night.
So, it looks like I will need to try grab the log from the chroot  
before it

is purged.

Thanks! I'm guessing this is some sort of timing issue, but it would
help to know where exactly to start debugging.



This is contents of tests/kdc/test-suite.log:

==
   Heimdal 1.6.99: tests/kdc/test-suite.log
==

# TOTAL: 18
# PASS:  16
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: check-hdb-mitdb
=

no MIT KDB support

FAIL: check-iprop
=

Creating database
Starting kdc
Waiting for KDC to start, looking logfile messages.log
Have waited 2 seconds
starting master
Waiting for ipropd-master to start, looking logfile messages.log
Have waited 2 seconds
starting slave
Waiting for ipropd-slave to start, looking logfile messages.log
Have waited 2 seconds
Have waited 4 seconds
Have waited 6 seconds
Have waited 8 seconds
Have waited 10 seconds
Have waited 12 seconds
Have waited 14 seconds
Have waited 16 seconds
Have waited 18 seconds
Have waited 20 seconds
Have waited 22 seconds
Have waited 24 seconds
Have waited 26 seconds
Have waited 28 seconds
Have waited 30 seconds
Have waited 32 seconds
Have waited 34 seconds
Have waited 36 seconds
Waited for 35 for the ipropd-slave to start, and it didnt happen
killing ipropd s + m + kdc
2014-04-25T01:47:57 error message: unable to find realm of host  
mx3210: -1765328167
2014-04-25T01:47:57 connection successful to master:  
localhost[127.0.0.1]
2014-04-25T01:47:57 error message: Matching credential (krbtgt/test.h5l...@test.h5l.se 
) not found: -1765328243
2014-04-25T01:47:57 error message: Matching credential (krbtgt/test.h5l...@test.h5l.se 
) not found: -1765328243
2014-04-25T01:47:57 error message: Matching credential (iprop/mx3...@test.h5l.se 
) not found: -1765328243
2014-04-25T01:47:57 error message: Matching credential (iprop/mx3...@test.h5l.se 
) not found: -1765328243
2014-04-25T01:47:57 krb5_sendauth: Matching credential (iprop/mx3...@test.h5l.se 
) not found

2014-04-25T01:47:57 disconnected for server
2014-04-25T01:47:57 krb5_recvauth: End of file
2014-04-25T01:47:57 sleeping 4 seconds before retrying to connect
Status for slaves, last updated: 2014-04-25T01:47:57

Master version: 29

Name  Address  Version  Status  Last Seen

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#745683: heimdal: FTBFS on hppa -- check-iprop test fails

[John David Anglin]

Package: heimdal
Version: 1.6~rc2+dfsg-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Since 1.6~rc2+dfsg-3, heimdal fails to build on hppa:
http://buildd.debian-ports.org/status/fetch.php?pkg=heimdalarch=hppaver=1.6%7Erc2%2Bdfsg-3stamp=1398141349

The check-iprop test fails causing build to fail.

Same error also seems to occur on ppc64.

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.1+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744207: cmake: FTBFS on hppa

[John David Anglin]

Package: cmake
Version: 2.8.12.1-1.1+b2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

See:
http://buildd.debian-ports.org/status/fetch.php?pkg=cmakearch=hppaver=2.8.12.1-1.2stamp=1397193614

It looks like the freetype bug isn't fixed.

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.0+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash

Versions of packages cmake depends on:
ii  cmake-data2.8.12.1-1.1
ii  libarchive13  3.1.2-8
ii  libc6 2.18-4+b1
ii  libcurl3  7.36.0-1+b1
ii  libexpat1 2.1.0-4+b1
ii  libgcc4   4.8.2-19
ii  libstdc++64.8.2-19
ii  procps1:3.3.9-3
ii  zlib1g1:1.2.8.dfsg-1+b1

Versions of packages cmake recommends:
ii  gcc   4:4.8.2-3
ii  make  3.81-8.3+b1

Versions of packages cmake suggests:
pn  codeblocks  none
pn  eclipse none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743833: gnat-4.6: no longer buildable on buildds

[John David Anglin]

Further, if one does a build outside buildd and then a +b1 inside  
buildd, the
results is no longer installable as it depends on a non existent +b1  
version

of gnat-4.6-base.

Cheers,
Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730885: cctools: FTBFS: globus_common_include.h:24:27: fatal error: globus_config.h: No such file or directory

[John David Anglin]

This also appears on hppa.  However, the bug does not appear to be in
cctools.

The include in globus_common_include.h is incorrect for multiarch  
systems.
globus_config.h is not installed in the same directory as  
globus_common_include.h.


The header is provided by libglobus-common-dev.

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743147: e2fsprogs: FTBFS on hppa: truncated crc headers using dietlibc

[John David Anglin]

Package: e2fsprogs
Version: 1.42.9-3
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

FTBFS:
http://buildd.debian-ports.org/status/fetch.php?pkg=e2fsprogsarch=hppaver=1.42.9-3stamp=1395956210

On inspecting the generated header causing the build failure, I saw
that it was truncated.  The attached patch fixes the problem by flushing
stdout prior to exiting in the main program.

With this change, e2fsprogs builds successfully.

-- System Information:
Debian Release: jessie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.14.0-rc8+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8)
Shell: /bin/sh linked to /bin/dash

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.42.9-2
ii  libblkid1   2.20.1-5.7
ii  libc6   2.18-4
ii  libcomerr2  1.42.9-2
ii  libss2  1.42.9-2
ii  libuuid12.20.1-5.7
ii  util-linux  2.20.1-5.7

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
ii  e2fsck-static  1.42.9-2
pn  gpart  none
ii  parted 2.3-17

-- no debconf information
Description: Flush stdout when generating crc headers
  When using dietlibc, the generated crc tables are truncated unless
  stdout is flushed.
Author: John David Anglin dave.ang...@bell.net
Bug-Debian: http://bugs.debian.org/bugnumber
Forwarded: not-needed
Author: John David Anglin dave.ang...@bell.net
Last-Update: 2014-03-30

--- e2fsprogs-1.42.9.orig/e2fsck/gen_crc32table.c
+++ e2fsprogs-1.42.9/e2fsck/gen_crc32table.c
@@ -97,5 +97,6 @@ int main(int argc ATTR((unused)), char**
 		printf(};\n);
 	}
 
+	fflush(stdout);
 	return 0;
 }
--- e2fsprogs-1.42.9.orig/lib/ext2fs/gen_crc32ctable.c
+++ e2fsprogs-1.42.9/lib/ext2fs/gen_crc32ctable.c
@@ -119,5 +119,6 @@ int main(int argc, char **argv)
 		output_table(crc32ctable_be, BE_TABLE_SIZE, 'b');
 	}
 
+	fflush(stdout);
 	return 0;
 }

Bug#729479: boost1.54: FTBFS on hppa -- BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS incorrectly defined

[John David Anglin]

Source: boost1.54
Version: 1.54.0-3
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

Build fails:

cp 
bin.v2/libs/wave/build/gcc-4.6/release/debug-symbols-on/link-static/threading-multi/libboost_wave.a
  stage/lib/libboost_wave.a

...failed updating 4 targets...
...skipped 9 targets...
...updated 1062 targets...
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory `/home/dave/debian/boost1.54/boost1.54-1.54.0'
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

See several compilation errors:

g++  -ftemplate-depth-128 -g -O2 -Wformat -Werror=format-security -O3 
-finline-functions -Wno-inline -Wall -g -D_FORTIFY_SOURCE=2 -pthread -fPIC 
-fno-stri
ct-aliasing -ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1
 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 
-DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL 
-DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_EVENT_LOG 
-DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 
-DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 
-DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 
-DDATE_TIME_INLINE -DNDEBUG  -I. -c -o 
bin.v2/libs/log/build/gcc-4.6/release/build-no/debug-symbols-on/log-api-unix/threading-multi/date_time_format_parser.o
 libs/log/src/date_time_format_parser.cppIn file included from 
./boost/math/special_functions/detail/round_fwd.hpp:12:0, from 
./boost/math/special_functions/math_fwd.hpp:26,
 from ./boost/math/special_functions/fpclassify.hpp:19,
 from ./boost/spirit/home/support/detail/sign.hpp:22,
 from ./boost/spirit/home/karma/numeric/detail/numeric_utils.hpp
:22,
 from ./boost/spirit/home/karma/numeric/uint.hpp:33,
 from ./boost/spirit/include/karma_uint.hpp:16,
 from libs/log/src/date_time_format_parser.cpp:19:
./boost/math/tools/promotion.hpp: In instantiation of 
‘boost::math::tools::promote_argslong double, float, float, float, float, 
float’:
./boost/math/special_functions/sign.hpp:114:50:   instantiated from ‘int 
boost::math::signbit(T) [with T = long double]’
./boost/spirit/home/support/detail/sign.hpp:47:51:   instantiated from ‘bool 
boost::spirit::detail::signbit(T) [with T = long double]’
./boost/spirit/home/karma/numeric/detail/numeric_utils.hpp:130:47:   
instantiated from here
./boost/math/tools/promotion.hpp:141:1: error: invalid application of ‘sizeof’ 
to incomplete type ‘boost::STATIC_ASSERTION_FAILUREfalse’ 
...failed gcc.compile.c++ 
bin.v2/libs/log/build/gcc-4.6/release/build-no/debug-symbols-on/log-api-unix/threading-multi/date_time_format_parser.o...
gcc.compile.c++ 
bin.v2/libs/log/build/gcc-4.6/release/build-no/debug-symbols-on/log-api-unix/threading-multi/named_scope_format_parser.o


-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.12.0+ (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- boost/math/tools/config.hpp.save	2013-04-15 04:47:08.0 -0400
+++ boost/math/tools/config.hpp	2013-11-13 07:39:23.713734222 -0500
@@ -24,7 +24,8 @@
 #include boost/math/tools/user.hpp
 
 #if (defined(__CYGWIN__) || defined(__FreeBSD__) || defined(__NetBSD__) \
-   || (defined(__hppa)  !defined(__OpenBSD__)) || (defined(__NO_LONG_DOUBLE_MATH)  (DBL_MANT_DIG != LDBL_MANT_DIG))) \
+   || (defined(__hppa)  !defined(__OpenBSD__)  !defined(__linux__)) \
+   || (defined(__NO_LONG_DOUBLE_MATH)  (DBL_MANT_DIG != LDBL_MANT_DIG))) \
 !defined(BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS)
 #  define BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS
 #endif

Bug#728547: sheepdog: FTBFS on hppa -- zookeeper not supported

[John David Anglin]

Package: sheepdog
Version: 0.7.3-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Zookeeper depends on default-jdk (= 1:1.6).  This in turn requires
openjdk which is not supported on hppa.

Built sheepdog by disabling zookeeper support.

-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.12.0-rc7+ (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sheepdog depends on:
ii  debconf [debconf-2.0]  1.5.51
ii  dpkg   1.17.1+b1
ii  libc6  2.17-93
ii  libcfg41.4.4-3
ii  libcpg41.4.4-3
ii  libfuse2   2.9.2-4

Versions of packages sheepdog recommends:
pn  corosync  none

sheepdog suggests no packages.

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726920: gst-plugins-good0.10: FTBFS with linux-headers-3.10-3

[John David Anglin]

Source: gst-plugins-good0.10
Version: 0.10.31-3+nmu1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

There are now two issues:

In file included from /usr/include/gstreamer-0.10/gst/gst.h:49:0,
 from /usr/include/gstreamer-0.10/gst/video/video.h:24,
 from gstv4l2bufferpool.c:33:
gstv4l2bufferpool.c: In function 'gst_v4l2_buffer_new':
gstv4l2bufferpool.c:184:66: error: 'struct v4l2_buffer' has no member named 
'input'
   GST_LOG_OBJECT (pool-v4l2elem,   input: %u, ret-vbuffer.input);
  ^
It appears from head that the member input has been removed.

v4l2_calls.c: In function 'gst_v4l2_fill_lists':
v4l2_calls.c:58:26: error: 'V4L2_CID_HCENTER_DEPRECATED' undeclared (first use 
in this function)
 #define V4L2_CID_HCENTER V4L2_CID_HCENTER_DEPRECATED
  ^
v4l2_calls.c:297:12: note: in expansion of macro 'V4L2_CID_HCENTER'
   case V4L2_CID_HCENTER:
^
v4l2_calls.c:58:26: note: each undeclared identifier is reported only once for 
each function it appears in
 #define V4L2_CID_HCENTER V4L2_CID_HCENTER_DEPRECATED
  ^
v4l2_calls.c:297:12: note: in expansion of macro 'V4L2_CID_HCENTER'
   case V4L2_CID_HCENTER:
^
v4l2_calls.c:61:26: error: 'V4L2_CID_VCENTER_DEPRECATED' undeclared (first use 
in this function)
 #define V4L2_CID_VCENTER V4L2_CID_VCENTER_DEPRECATED
  ^
v4l2_calls.c:298:12: note: in expansion of macro 'V4L2_CID_VCENTER'
   case V4L2_CID_VCENTER:
^
make[4]: *** [libgstvideo4linux2_la-v4l2_calls.lo] Error 1

These ioctls are now removed.

Two patches to work around problem are attached.

-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.10-3-parisc64-smp (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- ./sys/v4l2/gstv4l2bufferpool.c.save	2013-10-19 22:37:44.015077780 -0400
+++ ./sys/v4l2/gstv4l2bufferpool.c	2013-10-19 22:38:06.651290549 -0400
@@ -181,7 +181,7 @@
 GST_LOG_OBJECT (pool-v4l2elem,   MMAP offset:  %u,
 ret-vbuffer.m.offset);
   GST_LOG_OBJECT (pool-v4l2elem,   length:%u, ret-vbuffer.length);
-  GST_LOG_OBJECT (pool-v4l2elem,   input: %u, ret-vbuffer.input);
+  /* GST_LOG_OBJECT (pool-v4l2elem,   input: %u, ret-vbuffer.input); */
 
   data = (guint8 *) v4l2_mmap (0, ret-vbuffer.length,
   PROT_READ | PROT_WRITE, MAP_SHARED, pool-video_fd,
--- ./sys/v4l2/v4l2_calls.c.save	2012-02-17 05:48:47.0 -0500
+++ ./sys/v4l2/v4l2_calls.c	2013-10-19 22:47:51.628821842 -0400
@@ -53,14 +53,6 @@
 
 #include gst/gst-i18n-plugin.h
 
-/* Those are ioctl calls */
-#ifndef V4L2_CID_HCENTER
-#define V4L2_CID_HCENTER V4L2_CID_HCENTER_DEPRECATED
-#endif
-#ifndef V4L2_CID_VCENTER
-#define V4L2_CID_VCENTER V4L2_CID_VCENTER_DEPRECATED
-#endif
-
 GST_DEBUG_CATEGORY_EXTERN (v4l2_debug);
 #define GST_CAT_DEFAULT v4l2_debug
 
@@ -294,8 +286,6 @@
 break;
   case V4L2_CID_HFLIP:
   case V4L2_CID_VFLIP:
-  case V4L2_CID_HCENTER:
-  case V4L2_CID_VCENTER:
 #ifdef V4L2_CID_PAN_RESET
   case V4L2_CID_PAN_RESET:
 #endif

Bug#726347: Acknowledgement (samba: FTBFS on hppa: undefined krb5 references)

[John David Anglin]

Actually, the conflict is libkrb5-dev.  Had a successful build with it  
removed.


Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726871: gst-plugins-bad0.10: FTBFS -- stdafx.h in libalglib-dev conflicts with one in libmodplug-dev

[John David Anglin]

Source: gst-plugins-bad0.10
Version: 0.10.23-7.1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)

Build fails here:

libtool: compile:  g++-4.8 -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -pthr
ead -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/hppa-linux-
gnu/glib-2.0/include -I/usr/include/libxml2 -pthread -I/usr/include/gstreamer-0.
10 -I/usr/include/glib-2.0 -I/usr/lib/hppa-linux-gnu/glib-2.0/include -I/usr/inc
lude/libxml2 -DG_THREADS_MANDATORY -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -W
all -Wmissing-declarations -Wredundant-decls -Wwrite-strings -Wformat-nonliteral
 -Wformat-security -Winit-self -Wmissing-include-dirs -Waddress -Wno-multichar -
g -g -O2 -Wformat -Werror=format-security -Wall -Wno-error -c gstmodplug.cc  -fP
IC -DPIC -o .libs/libgstmodplug_la-gstmodplug.o
In file included from gstmodplug.cc:54:0:
/usr/include/libmodplug/sndfile.h:21:15: error: 'BYTE' does not name a type
 typedef const BYTE * LPCBYTE;
   ^
This occurs in native build.  In order to avoid conflict, gstmodplug.cc
should include libmodplug/stdafx.h.

-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.10-3-parisc64-smp (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- ./ext/modplug/gstmodplug.cc.save	2012-01-18 07:32:55.0 -0500
+++ ./ext/modplug/gstmodplug.cc	2013-10-19 20:53:05.268464573 -0400
@@ -50,7 +50,7 @@
 #define WORDS_BIGENDIAN 0
 #endif
 
-#include stdafx.h
+#include libmodplug/stdafx.h
 #include libmodplug/sndfile.h
 
 #include gstmodplug.h

Bug#718733: python-qt4: FTBFS on hppa -- 4.10.2-2

[John David Anglin]

Package: python-qt4
Version: 4.10.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

touch dbg-build-3.3/build-stamp
[37474 refs]
dh_testdir
mkdir -p dbg-build-3.2
cd dbg-build-3.2  python3.2-dbg ../configure.py --confirm-license --verbose 
-q /usr/bin/qmake-qt4 -c -j 10 LIBDIR_QT=/usr/lib STRIP= MOC=moc-qt4 
LIBS_OPENGL= LIBS_X11= LIBS_THREAD= CFLAGS= CFLAGS_RELEASE= -g -O2 
-Wformat -Werror=format-security  -D_FORTIFY_SOURCE=2 LFLAGS= 
CXXFLAGS_RELEASE= -g -O2 -Wformat -Werror=format-security  
-D_FORTIFY_SOURCE=2 LFLAGS_RELEASE=  -Wl,-O1 \
-m /usr/lib/python3.2/config-3.2dmu \
-l /usr/include/python3.2dm \
-d /usr/lib/python3.2/dist-packages \
--no-designer-plugin
Usage: python configure.py [opts] [macro=value] [macro+=value]

configure.py: error: '/usr/include/python3.2dm' is not a directory
[55306 refs]
make: *** [dbg-build-3.2/configure-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
Build command 'cd python-qt4-4.10.2  dpkg-buildpackage -b -uc' failed.
Fetched 11.3 MB in 18s (623 kB/s)
E: Child process failed

I see following python directories in /usr/include:

dave@mx3210:~$ ls -ld /usr/include/python*
drwxr-xr-x 2 root root   72 Jun 14 08:44 /usr/include/python2.6
drwxr-xr-x 2 root root 4096 Jun 14 08:44 /usr/include/python2.6_d
drwxr-xr-x 2 root root 4096 Jun 15 08:59 /usr/include/python2.7
drwxr-xr-x 2 root root 4096 Jun 15 08:59 /usr/include/python2.7_d
lrwxrwxrwx 1 root root   11 Jun  5  2011 /usr/include/python3.2 - python3.2mu
lrwxrwxrwx 1 root root   12 Oct  1  2011 /usr/include/python3.2_d - 
python3.2dmu
drwxr-xr-x 2 root root 4096 Jul 15 21:16 /usr/include/python3.2dmu
drwxr-xr-x 2 root root 4096 Jul 15 21:17 /usr/include/python3.2mu
lrwxrwxrwx 1 root root   10 May  7 09:16 /usr/include/python3.3 - python3.3m
drwxr-xr-x 2 root root 4096 Jun 18 20:55 /usr/include/python3.3dm
drwxr-xr-x 2 root root 4096 Jun 18 20:55 /usr/include/python3.3m


-- System Information:
Debian Release: 7.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 3.11.0-rc3+ (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-qt4 depends on:
ii  libc6 2.17-91
ii  libgcc4   4.8.1-8
ii  libpython2.7  2.7.5-6
ii  libqt4-dbus   4:4.8.5+dfsg-2
ii  libqt4-declarative4:4.8.5+dfsg-2
ii  libqt4-designer   4:4.8.5+dfsg-2
ii  libqt4-help   4:4.8.5+dfsg-2
ii  libqt4-network4:4.8.5+dfsg-2
ii  libqt4-script 4:4.8.5+dfsg-2
ii  libqt4-scripttools4:4.8.5+dfsg-2
ii  libqt4-svg4:4.8.5+dfsg-2
ii  libqt4-test   4:4.8.5+dfsg-2
ii  libqt4-xml4:4.8.5+dfsg-2
ii  libqt4-xmlpatterns4:4.8.5+dfsg-2
ii  libqtassistantclient4 4.6.3-4+b1
ii  libqtcore44:4.8.5+dfsg-2
ii  libqtgui4 4:4.8.5+dfsg-2
ii  libqtwebkit4  2.2.1-5+b1
ii  libstdc++64.8.1-8
ii  python2.7.3-5
ii  python-sip [sip-api-9.2]  4.14.6-1

python-qt4 recommends no packages.

Versions of packages python-qt4 suggests:
pn  python-qt4-dbg  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710703: Acknowledgement (avogadro: FTBFS on hppa: expected unqualified-id before ‘;’ token)

[John David Anglin]

Wrong python library was found during configuration:

-- [2/5] Python Libraries
-- Found PythonLibs: /usr/lib/hppa-linux-gnu/libpython3.3m.so (found  
version 3.3.2+) 
-- [3/5] Python Interpreter
-- Found PythonInterp: /usr/bin/python (found version 2.7.5) 
-- [4/5] Numpy Module

-- Numpy headers found
-- [5/5] SIP Module
-- Found sip.h header...
-- All python dependencies found - Python support enabled
-- GLEW found and GLSL support enabled
-- Threaded OpenGL rendering not enabled
-- Setting new boost python libraries
-- Enabled python terminal
-- Python site-packages directory: /usr/lib/python2.7/dist-packages

Something like the following in rules avoids the error:

override_dh_auto_configure:
dh_auto_configure -- \
-DENABLE_GLSL=ON \
-DENABLE_RPATH=OFF \
-DENABLE_UPDATE_CHECKER=OFF \
-DPYTHON_EXECUTABLE=/usr/bin/python \
-DPYTHON_LIBRARY=/usr/lib/hppa-linux-gnu/libpython2.7.so \
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7

Dave
--
John David Anglin   dave.ang...@bell.net


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[John David Anglin]

On Wed, 02 Jun 2010, Modestas Vainius wrote:

 Hello,
 
 this bug [1] is back to the very common department with eglibc 2.11 (libc6-
 dev_2.11.1-1) builds. Majority of KDE applications are failing to build on 
 hppa again. Is there really nothing what could be done to fix it?

I will just say it is very tricky.  I think a fix is possible (arm and mips
had similar cache problems) but the victim replacement present in PA8800/PA8900
caches makes the problem especially difficult  for hardware using these
processors.

I have spent the last few months testing various alternatives and have
now done hundreds of kernel builds.  I did post some experimental patches
that fix the problem on UP kernels.  However, the problem is not resolved
for SMP kernels.

The minifail test is a good one to demonstrate the problem.  Indeed,
a very similar test was given in the thread below:
http://readlist.com/lists/vger.kernel.org/linux-kernel/54/270861.html

This thread also discusses the PA8800 problem:
http://readlist.com/lists/vger.kernel.org/linux-kernel/54/271417.html

I currently surmise that we have a problem with the cache victim
replacement, although the cause isn't clear.  I did find recently
that the cache prefetch in copy_user_page_asm extends to the line
beyond the end of the page, but fixing this doesn't resolve the problem.

I am still experimenting with using equivalent aliasing.  It does
help to flush in ptep_set_wrprotect.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[John David Anglin]

On Thu, 08 Apr 2010, Helge Deller wrote:

 On 04/02/2010 09:35 PM, John David Anglin wrote:
  On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
  
  NIIBE Yutaka wrote:
  To have same semantics as other archs, I think that VIPT-WB cache
  machine should have cache flush at ptep_set_wrprotect, so that memory
  of the page has up-to-date data.  Yes, it will be huge performance
  impact for fork.  But I don't find any good solution other than this
  yet.
 
  I think we could do something like (only for VIPT-WB cache machine):
 
  -  static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned 
  long 
  address, pte_t *ptep)
 
  +  static inline void ptep_set_wrprotect(struct vm_area_struct *vma, 
  struct 
  mm_struct *mm, unsigned long addr, pte_t *ptep)
 {
 pte_t old_pte = *ptep;
  +  if (atomic_read(mm-mm_users)  1)
  +  flush_cache_page(vma, addr, pte_pfn(old_pte));
 set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
 }
  
  I tested the hack below on two machines currently running 2.6.33.2
  UP kernels.  The change seems to fix Debian #561203 (minifail bug)!
  Thus, I definitely think you are on the right track.  I'll continue
  to test.
  
  I suspect the same issue is present for SMP kernels.
 
 Hi Dave,
 
 I tested your patch today on one of my machines with plain kernel 2.6.33 
 (32bit, SMP, B2000 I think).
 Sadly I still did see the minifail bug.
 
 Are you sure, that the patch fixed this bug for you?

Seemed to, but I have a bunch of other changes installed.  Possibly,
the change to cacheflush.h is important.  It affects all PA8000.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

diff --git a/arch/parisc/hpux/wrappers.S b/arch/parisc/hpux/wrappers.S
index 58c53c8..bdcea33 100644
--- a/arch/parisc/hpux/wrappers.S
+++ b/arch/parisc/hpux/wrappers.S
@@ -88,7 +88,7 @@ ENTRY(hpux_fork_wrapper)
 
STREG   %r2,-20(%r30)
ldo 64(%r30),%r30
-   STREG   %r2,PT_GR19(%r1);! save for child
+   STREG   %r2,PT_SYSCALL_RP(%r1)  ;! save for child
STREG   %r30,PT_GR21(%r1)   ;! save for child
 
LDREG   PT_GR30(%r1),%r25
@@ -132,7 +132,7 @@ ENTRY(hpux_child_return)
bl,nschedule_tail, %r2
 #endif
 
-   LDREG   TASK_PT_GR19-TASK_SZ_ALGN-128(%r30),%r2
+   LDREG   TASK_PT_SYSCALL_RP-TASK_SZ_ALGN-128(%r30),%r2
b fork_return
copy %r0,%r28
 ENDPROC(hpux_child_return)
diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index 716634d..d7fabc4 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -24,29 +24,46 @@
  * Hash function to index into a different SPINLOCK.
  * Since a is usually an address, use one spinlock per cacheline.
  */
-#  define ATOMIC_HASH_SIZE 4
-#  define ATOMIC_HASH(a) ((__atomic_hash[ (((unsigned long) 
(a))/L1_CACHE_BYTES)  (ATOMIC_HASH_SIZE-1) ]))
+#  define ATOMIC_HASH_SIZE (4096/L1_CACHE_BYTES)  /* 4 */
+#  define ATOMIC_HASH(a)  ((__atomic_hash[ (((unsigned long) 
(a))/L1_CACHE_BYTES)  (ATOMIC_HASH_SIZE-1) ]))
+#  define ATOMIC_USER_HASH(a) ((__atomic_user_hash[ (((unsigned long) 
(a))/L1_CACHE_BYTES)  (ATOMIC_HASH_SIZE-1) ]))
 
 extern arch_spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] __lock_aligned;
+extern arch_spinlock_t __atomic_user_hash[ATOMIC_HASH_SIZE] __lock_aligned;
 
 /* Can't use raw_spin_lock_irq because of #include problems, so
  * this is the substitute */
-#define _atomic_spin_lock_irqsave(l,f) do {\
-   arch_spinlock_t *s = ATOMIC_HASH(l);\
+#define _atomic_spin_lock_irqsave_template(l,f,hash_func) do { \
+   arch_spinlock_t *s = hash_func; \
local_irq_save(f);  \
arch_spin_lock(s);  \
 } while(0)
 
-#define _atomic_spin_unlock_irqrestore(l,f) do {   \
-   arch_spinlock_t *s = ATOMIC_HASH(l);\
+#define _atomic_spin_unlock_irqrestore_template(l,f,hash_func) do {\
+   arch_spinlock_t *s = hash_func; \
arch_spin_unlock(s);\
local_irq_restore(f);   \
 } while(0)
 
+/* kernel memory locks */
+#define _atomic_spin_lock_irqsave(l,f) \
+   _atomic_spin_lock_irqsave_template(l,f,ATOMIC_HASH(l))
+
+#define _atomic_spin_unlock_irqrestore(l,f)\
+   _atomic_spin_unlock_irqrestore_template(l,f,ATOMIC_HASH(l))
+
+/* userspace memory locks */
+#define _atomic_spin_lock_irqsave_user(l,f)\
+   _atomic_spin_lock_irqsave_template(l,f,ATOMIC_USER_HASH(l))
+
+#define _atomic_spin_unlock_irqrestore_user(l,f)   \
+   _atomic_spin_unlock_irqrestore_template(l,f,ATOMIC_USER_HASH(l))
 
 #else
 #  define _atomic_spin_lock_irqsave(l,f) do { local_irq_save(f); } while (0)
 #  define _atomic_spin_unlock_irqrestore(l,f) do { local_irq_restore(f); } 
while

Bug#561203: threads and fork on machine with VIPT-WB cache

[John David Anglin]

 On Thu, 08 Apr 2010, Helge Deller wrote:

  I tested your patch today on one of my machines with plain kernel 2.6.33 
  (32bit, SMP, B2000 I think).
  Sadly I still did see the minifail bug.
  
  Are you sure, that the patch fixed this bug for you?
 
 Seemed to, but I have a bunch of other changes installed.  Possibly,
 the change to cacheflush.h is important.  It affects all PA8000.

I also think the change suggested by James

+   if (pte_dirty(old_pte))

is important for SMP.  With the patch set that I sent, my rp3440 and
gsyprf11 seem reasonably stable running 2.6.33.2 SMP.  I doubt all
problems are solved but things are a lot better than before.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[John David Anglin]

 Thanks a lot for the discussion.
 
 James Bottomley wrote:
  So your theory is that the data the kernel sees doing the page copy can
  be stale because of dirty cache lines in userspace (which is certainly
  possible in the ordinary way)?
 
 Yes.
 
  By design that shouldn't happen: the idea behind COW breaking is
  that before it breaks, the page is read only ... this means that
  processes can have clean cache copies of it, but never dirty cache
  copies (because writes are forbidden).
 
 That must be design, I agree.
 
 To keep this condition (no dirty cache for COW page), we need to flush
 cache before ptep_set_wrprotect.  That's my point.
 
 Please look at the code path:
(kernel/fork.c)
do_fork - copy_process - copy_mm - dup_mm - dup_mmap -
(mm/memory.c)
copy_page_range - copy_p*d_range - copy_one_pte - ptep_set_wrprotect
 
 The function flush_cache_dup_mm is called from dup_mmap, that's enough
 for a case of a process with single thread.
 I think that:
 We need to flush cache before ptep_set_wrprotect for a process with
 multiple threads.  Other threads may change memory after a thread
 invokes do_fork and before calling ptep_set_wrprotect.  Specifically,
 a process may sleep at pte_alloc function to get a page.

I agree.  It is interesting that in the case of the Debian bug that
a thread of the parent process causes the COW break and thereby corrupts
its own memory.  As far as I can tell, the fork'd child never writes
to the memory that causes the fault.

My testing indicates that your suggested change fixes the Debian
bug.  I've attached below my latest test version.  This seems to fix
the bug on both SMP and UP kernels.

However, it doesn't fix all page/cache related issues on parisc
SMP kernels that I commonly see.

My first inclination after even before reading your analysis was
to assume that copy_user_page was broken (i.e, that even if a
processor cache was dirty when the COW page was write protected,
it should be possible to do the flush before the page is copied).
However, this didn't seem to work...  Possibly, there are issues
with aliased addresses.

I note that sparc flushes the entire cache and purges the entire
tlb in kmap_atomic/kunmap_atomic for highmem.  Although the breakage
that I see is not limited to PA8800/PA8900, I'm not convinced
that we maintain coherency that is required for these processors
in copy_user_page when we have multiple threads.

As a side note, kmap_atomic/kunmap_atomic seem to lack calls to
pagefault_disable()/pagefault_enable() on PA8800.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

diff --git a/arch/parisc/include/asm/pgtable.h 
b/arch/parisc/include/asm/pgtable.h
index a27d2e2..b140d5c 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -14,6 +14,7 @@
 #include linux/bitops.h
 #include asm/processor.h
 #include asm/cache.h
+extern void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, 
unsigned long pfn);
 
 /*
  * kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
@@ -456,17 +457,22 @@ static inline pte_t ptep_get_and_clear(struct mm_struct 
*mm, unsigned long addr,
return old_pte;
 }
 
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long 
addr, pte_t *ptep)
+static inline void ptep_set_wrprotect(struct vm_area_struct *vma, struct 
mm_struct *mm, unsigned long addr, pte_t *ptep)
 {
 #ifdef CONFIG_SMP
unsigned long new, old;
+#endif
+   pte_t old_pte = *ptep;
+
+   if (atomic_read(mm-mm_users)  1)
+   flush_cache_page(vma, addr, pte_pfn(old_pte));
 
+#ifdef CONFIG_SMP
do {
old = pte_val(*ptep);
new = pte_val(pte_wrprotect(__pte (old)));
} while (cmpxchg((unsigned long *) ptep, old, new) != old);
 #else
-   pte_t old_pte = *ptep;
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
 #endif
 }
diff --git a/mm/memory.c b/mm/memory.c
index 09e4b1b..21c2916 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -616,7 +616,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct 
*src_mm,
 * in the parent and the child
 */
if (is_cow_mapping(vm_flags)) {
-   ptep_set_wrprotect(src_mm, addr, src_pte);
+   ptep_set_wrprotect(vma, src_mm, addr, src_pte);
pte = pte_wrprotect(pte);
}
 



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[John David Anglin]

   By design that shouldn't happen: the idea behind COW breaking is
   that before it breaks, the page is read only ... this means that
   processes can have clean cache copies of it, but never dirty cache
   copies (because writes are forbidden).
  
  That must be design, I agree.
  
  To keep this condition (no dirty cache for COW page), we need to flush
  cache before ptep_set_wrprotect.  That's my point.

Is it possible that a sleep/reschedule could cause the cache to become
dirty again before it is write protected?

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[John David Anglin]

On Fri, 02 Apr 2010, NIIBE Yutaka wrote:

 NIIBE Yutaka wrote:
 To have same semantics as other archs, I think that VIPT-WB cache
 machine should have cache flush at ptep_set_wrprotect, so that memory
 of the page has up-to-date data.  Yes, it will be huge performance
 impact for fork.  But I don't find any good solution other than this
 yet.

 I think we could do something like (only for VIPT-WB cache machine):

 - static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned 
 long 
 address, pte_t *ptep)

 + static inline void ptep_set_wrprotect(struct vm_area_struct *vma, 
 struct 
 mm_struct *mm, unsigned long addr, pte_t *ptep)
   {
   pte_t old_pte = *ptep;
 + if (atomic_read(mm-mm_users)  1)
 + flush_cache_page(vma, addr, pte_pfn(old_pte));
   set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
   }

I tested the hack below on two machines currently running 2.6.33.2
UP kernels.  The change seems to fix Debian #561203 (minifail bug)!
Thus, I definitely think you are on the right track.  I'll continue
to test.

I suspect the same issue is present for SMP kernels.

Thanks,
Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

diff --git a/arch/parisc/include/asm/pgtable.h 
b/arch/parisc/include/asm/pgtable.h
index a27d2e2..a5d730f 100644
--- a/arch/parisc/include/asm/pgtable.h
+++ b/arch/parisc/include/asm/pgtable.h
@@ -14,6 +14,7 @@
 #include linux/bitops.h
 #include asm/processor.h
 #include asm/cache.h
+extern void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, 
unsigned long pfn);
 
 /*
  * kern_addr_valid(ADDR) tests if ADDR is pointing to valid kernel
@@ -456,7 +457,7 @@ static inline pte_t ptep_get_and_clear(struct mm_struct 
*mm, unsigned long addr,
return old_pte;
 }
 
-static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long 
addr, pte_t *ptep)
+static inline void ptep_set_wrprotect(struct vm_area_struct *vma, struct 
mm_struct *mm, unsigned long addr, pte_t *ptep)
 {
 #ifdef CONFIG_SMP
unsigned long new, old;
@@ -467,6 +468,8 @@ static inline void ptep_set_wrprotect(struct mm_struct *mm, 
unsigned long addr,
} while (cmpxchg((unsigned long *) ptep, old, new) != old);
 #else
pte_t old_pte = *ptep;
+   if (atomic_read(mm-mm_users)  1)
+   flush_cache_page(vma, addr, pte_pfn(old_pte));
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
 #endif
 }
diff --git a/mm/memory.c b/mm/memory.c
index 09e4b1b..21c2916 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -616,7 +616,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct 
*src_mm,
 * in the parent and the child
 */
if (is_cow_mapping(vm_flags)) {
-   ptep_set_wrprotect(src_mm, addr, src_pte);
+   ptep_set_wrprotect(vma, src_mm, addr, src_pte);
pte = pte_wrprotect(pte);
}
 



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference

[John David Anglin]

 John David Anglin wrote:
  John David Anglin wrote:
  Moreover, I have downloaded the package from
  http://packages.debian.org/squeeze/hppa/libpt2.6.5/download and
  extracted the lib.  IIUC, that function is there indeed (the first is on
  my amd64 machine, the second is hppa extracted file):
 
  snoopy:~$ nm -D /usr/lib/libpt.so.2.6-beta7 |grep Trigger
  0020d850 T _ZN12PVXMLSession7TriggerEv
  0020d840 T _ZThn1096_N12PVXMLSession7TriggerEv
  snoopy:~$ nm -D libpt.so.2.6.5 |grep Trigger
  001abb74 T _ZN12PVXMLSession7TriggerEv
  001abb6c T _ZThn1152_N12PVXMLSession7TriggerEv
  snoopy:~$
  The latter symbol is the symbol of interest.  Would you run the link
  command with --trace-symbol=_ZThn1152_N12PVXMLSession7TriggerEv to find
  the name of the linked file which references the symbol.
 
  It may be the link order is bad.
  /home/dedu/softs/ekiga/ptlib/lib_linux_x86_64/obj/vxml.o: definition of
  non-virtual thunk to PVXMLSession::Trigger()
  
  We need to know which file references the symbol.  Does adding -lpt
  at the end of the g++ link command resolve the problem?
 
 Well, I know the source file with the symbol.  It's src/ptclib/vxml.cxx,
 see
 http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/tags/v2_6_5/src/ptclib/vxml.cxx?revision=23495view=markup

You misunderstood my comment.  It's necessary to know which files
reference this symbol in order to determine whether this is just an
error in the link command, or the linker itself.

 (If you prefer, we can also wait about one week, when probably another
 ptlib and opal version are released upstream, and they will be packaged.)

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference

[John David Anglin]

 John David Anglin wrote:
  John David Anglin wrote:
  John David Anglin wrote:
  Moreover, I have downloaded the package from
  http://packages.debian.org/squeeze/hppa/libpt2.6.5/download and
  extracted the lib.  IIUC, that function is there indeed (the first is 
  on
  my amd64 machine, the second is hppa extracted file):
 
  snoopy:~$ nm -D /usr/lib/libpt.so.2.6-beta7 |grep Trigger
  0020d850 T _ZN12PVXMLSession7TriggerEv
  0020d840 T _ZThn1096_N12PVXMLSession7TriggerEv
  snoopy:~$ nm -D libpt.so.2.6.5 |grep Trigger
  001abb74 T _ZN12PVXMLSession7TriggerEv
  001abb6c T _ZThn1152_N12PVXMLSession7TriggerEv
  snoopy:~$
  The latter symbol is the symbol of interest.  Would you run the link
  command with --trace-symbol=_ZThn1152_N12PVXMLSession7TriggerEv to find
  the name of the linked file which references the symbol.
 
  It may be the link order is bad.
  /home/dedu/softs/ekiga/ptlib/lib_linux_x86_64/obj/vxml.o: definition of
  non-virtual thunk to PVXMLSession::Trigger()
  We need to know which file references the symbol.  Does adding -lpt
  at the end of the g++ link command resolve the problem?
  Well, I know the source file with the symbol.  It's src/ptclib/vxml.cxx,
  see
  http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/ptlib/tags/v2_6_5/src/ptclib/vxml.cxx?revision=23495view=markup
  
  You misunderstood my comment.  It's necessary to know which files
  reference this symbol in order to determine whether this is just an
  error in the link command, or the linker itself.
 
 So you want that I add -lpt at the end of the following line:
 
 g++ obj_linux_hppa/main.o  -lopal -lpt -lpthread -lrt -lsasl2 -lldap
 -llber -lldap_r -lssl -lcrypto -lexpat -lSDL -lodbc -lresolv -ldl
 -lspeexdsp   -L ../../lib* -o obj_linux_hppa/simpleopal
 
 but on a hppa architecture, is that right?

Can't hurt.

I just noticed the `../../lib*' in the link command.  It could
be a problem.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference to `non-virtual thunk to PVXMLSession::Trigger()'

[John David Anglin]

On Thu, 18 Mar 2010, Carlos O'Donell wrote:

 On Thu, Mar 18, 2010 at 7:47 AM, Adam D. Barratt
 a...@adam-barratt.org.uk wrote:
  ../../lib_linux_hppa/libopal.so: undefined reference to `non-virtual
  thunk to PVXMLSession::Trigger()'
 
 What does this error mean?

The symbol was not found by ld.  I see in the bug report log:

g++ obj_linux_hppa/main.o  -lopal -lpt -lpthread -lrt -lsasl2 -lldap -llber 
-lldap_r -lssl -lcrypto -lexpat -lSDL -lodbc -lresolv -ldl -lspeexdsp   -L 
../../lib* -o obj_linux_hppa/simpleopal
../../lib_linux_hppa/libopal.so: undefined reference to `non-virtual thunk to 
PVXMLSession::Trigger()'
../../lib_linux_hppa/libopal.so: undefined reference to `non-virtual thunk to 
PVXMLSession::OnEndRecording(PString const)'
../../lib_linux_hppa/libopal.so: undefined reference to `non-virtual thunk to 
PVXMLSession::RecordEnd()'
collect2: ld returned 1 exit status
make[1]: *** [obj_linux_hppa/simpleopal] Error 1

Check that that the library that is supposed to provide these symbols (libpt?)
provides them.

You can see more info about link by adding -Wl,-v -Wl,-debug to the above g++
command.

Regarding the tool change differences between 4.3 and 4.4, there is no
difference in the handling of thunks in the hppa backend.  So, any
differences that you see are due to changes to the main GCC code, etc.
It may be the references are not present in the 4.3 compiled code.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference

[John David Anglin]

 Moreover, I have downloaded the package from
 http://packages.debian.org/squeeze/hppa/libpt2.6.5/download and
 extracted the lib.  IIUC, that function is there indeed (the first is on
 my amd64 machine, the second is hppa extracted file):
 
 snoopy:~$ nm -D /usr/lib/libpt.so.2.6-beta7 |grep Trigger
 0020d850 T _ZN12PVXMLSession7TriggerEv
 0020d840 T _ZThn1096_N12PVXMLSession7TriggerEv
 snoopy:~$ nm -D libpt.so.2.6.5 |grep Trigger
 001abb74 T _ZN12PVXMLSession7TriggerEv
 001abb6c T _ZThn1152_N12PVXMLSession7TriggerEv
 snoopy:~$

The latter symbol is the symbol of interest.  Would you run the link
command with --trace-symbol=_ZThn1152_N12PVXMLSession7TriggerEv to find
the name of the linked file which references the symbol.

It may be the link order is bad.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference

[John David Anglin]

 John David Anglin wrote:
  Moreover, I have downloaded the package from
  http://packages.debian.org/squeeze/hppa/libpt2.6.5/download and
  extracted the lib.  IIUC, that function is there indeed (the first is on
  my amd64 machine, the second is hppa extracted file):
 
  snoopy:~$ nm -D /usr/lib/libpt.so.2.6-beta7 |grep Trigger
  0020d850 T _ZN12PVXMLSession7TriggerEv
  0020d840 T _ZThn1096_N12PVXMLSession7TriggerEv
  snoopy:~$ nm -D libpt.so.2.6.5 |grep Trigger
  001abb74 T _ZN12PVXMLSession7TriggerEv
  001abb6c T _ZThn1152_N12PVXMLSession7TriggerEv
  snoopy:~$
  
  The latter symbol is the symbol of interest.  Would you run the link
  command with --trace-symbol=_ZThn1152_N12PVXMLSession7TriggerEv to find
  the name of the linked file which references the symbol.
  
  It may be the link order is bad.
 
 /home/dedu/softs/ekiga/ptlib/lib_linux_x86_64/obj/vxml.o: definition of
 non-virtual thunk to PVXMLSession::Trigger()

We need to know which file references the symbol.  Does adding -lpt
at the end of the g++ link command resolve the problem?

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#558980: access to hppa machine to work on Bug#558980

[John David Anglin]

 On Mon, Dec 14, 2009 at 07:46:52AM -0500, Stephen Leake wrote:
 ...
  Ludovic also suggested removing '-fstack-check' from the list of
  compiler options. I did that, rebuilt the static and dynamic
  libraries, and the bug went away; the test code works with both static
  and dynamic libraries.
 
 Dave, Carlos,
 Would this imply something might be broken in the stack unwinding?

Possibly.  An off by one error was recently fixed on GCC head.
This affects Ada but not Java.  Java had code to adjust the program
counter by one instruction when catching signals.  The change could
be backported to 4.4, but I don't intend to do it because the behavior
isn't a regression and it changes the behavior of libgcc_s.so.  We
need a version bump for libgcc_s.so in 4.5.

We don't have any backend support for '-fstack-check'.  Eric
Botcazou has recently done some updates which I think fix some issues
with generic stack checking.  See for example,

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548

So, it might help to try a recent 4.5.0 snapshot.

The fact that the stack grows upwards on hppa is a bit unusual and
might be a source of problems.  It is possible that we could add backend
support for stack checking using the probe instruction, etc, but I don't
have time to look into it until we finish moving.  There's still a few
remaining issues for 4.5.0 to be addressed.

 Or is this more likely to be something specific to Gnu ADA?

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

On Mon, 23 Nov 2009, Carlos O'Donell wrote:

 I can successfully run apt-get with the new libstdc++6 that I just built.
 
 The testsuite result is cleaner:
 ~~~
 FAIL: 29_atomics/atomic_flag/clear/1.c execution test
 FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
 
 === libstdc++ Summary ===
 
 # of expected passes5880
 # of unexpected failures2
 # of expected failures  80
 # of unsupported tests  331

There are a couple of issues wrt running the libstdc++6 testsuite:

1) The locale tests require a certain minimal set of foreign locales
to run.  Simplest may be to install all locales.

2) In order to use the generic code using the the atomic builtins,
a patch is needed.  I have recently tested the attached two changes
provided by Matthias.  In addition, the undef and define for LIB_SPEC
in pa-linux.h should be removed.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)
# DP: Do link tests to check for the atomic builtins

2009-05-03  Paolo Carlini  paolo.carl...@oracle.com

* acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): Do link tests when
possible.
* configure: Regenerate.

Index: acinclude.m4
===
--- a/src/libstdc++-v3/acinclude.m4 (revision 147071)
+++ b/src/libstdc++-v3/acinclude.m4 (working copy)
@@ -2429,8 +2429,7 @@
 dnl that are used should be checked.
 dnl
 dnl Note:
-dnl libgomp and libgfortran do this with a link test, instead of an asm test.
-dnl see: CHECK_SYNC_FETCH_AND_ADD
+dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD.
 dnl
 dnl Defines:
 dnl  _GLIBCXX_ATOMIC_BUILTINS_1 
@@ -2442,12 +2441,110 @@
   AC_LANG_SAVE
   AC_LANG_CPLUSPLUS
   old_CXXFLAGS=$CXXFLAGS
-  
+
+  # Do link tests if possible, instead asm tests.
+  if test x$gcc_no_link != xyes; then  
+
+  # Can do link tests.
+
+  CXXFLAGS=$CXXFLAGS -fno-exceptions
+
+  AC_MSG_CHECKING([for atomic builtins for bool])
+  AC_CACHE_VAL(glibcxx_cv_atomic_bool, [
+AC_TRY_LINK(
+  [ ],
+  [typedef bool atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(c1, c2);
+   __sync_val_compare_and_swap(c1, c3, c2);
+   __sync_lock_test_and_set(c1, c3);
+   __sync_lock_release(c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_bool=yes],
+  [glibcxx_cv_atomic_bool=no])
+  ])
+  if test $glibcxx_cv_atomic_bool = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1,
+  [Define if builtin atomic operations for bool are supported on this 
host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_bool)
+
+  AC_MSG_CHECKING([for atomic builtins for short])
+  AC_CACHE_VAL(glibcxx_cv_atomic_short, [
+AC_TRY_LINK(
+  [ ],
+  [typedef short atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(c1, c2);
+   __sync_val_compare_and_swap(c1, c3, c2);
+   __sync_lock_test_and_set(c1, c3);
+   __sync_lock_release(c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_short=yes],
+  [glibcxx_cv_atomic_short=no])
+  ])
+  if test $glibcxx_cv_atomic_short = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1,
+  [Define if builtin atomic operations for short are supported on this 
host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_short)
+
+  AC_MSG_CHECKING([for atomic builtins for int])
+  AC_CACHE_VAL(glibcxx_cv_atomic_int, [
+AC_TRY_LINK(
+  [ ],
+  [typedef int atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(c1, c2);
+   __sync_val_compare_and_swap(c1, c3, c2);
+   __sync_lock_test_and_set(c1, c3);
+   __sync_lock_release(c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_int=yes],
+  [glibcxx_cv_atomic_int=no])
+  ])
+  if test $glibcxx_cv_atomic_int = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1,
+  [Define if builtin atomic operations for int are supported on this 
host.])
+  fi
+  AC_MSG_RESULT($glibcxx_cv_atomic_int)
+
+  AC_MSG_CHECKING([for atomic builtins for long long])
+  AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [
+AC_TRY_LINK(
+  [ ],
+  [typedef long long atomic_type;
+   atomic_type c1;
+   atomic_type c2;
+   const atomic_type c3(0);
+   __sync_fetch_and_add(c1, c2);
+   __sync_val_compare_and_swap(c1, c3, c2);
+   __sync_lock_test_and_set(c1, c3);
+   __sync_lock_release(c1);
+   __sync_synchronize();],
+  [glibcxx_cv_atomic_long_long=yes],
+  [glibcxx_cv_atomic_long_long=no])
+  ])
+  if test $glibcxx_cv_atomic_long_long = yes; then
+AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1,
+  [Define if builtin atomic operations for long 

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

  The problem appears to have gone away with head.  I don't see it with
  hpux.
  
 
 Note that latest version of gcc 4.4 in Debian is built with
 --disable-libstdcxx-pch, but the segfault is this present :(

Personally, I don't believe the segfault is related to the FAILs
seen in the libstdc++ testsuite.  As you showed, there is an ABI
change in the library depending on libc version.  Someone needs
to generate a backtrace so that we can get some idea what's happening.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

 
 On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
 car...@systemhalted.org wrote:
  This happens because the original locale object was created at address
  0xbff01c20. However, when apt-get calls std::basic_ioschar,
  std::char_traitschar ::init it passes in the address 0xbff01c18.
  So we went from a constructor using this as 0xbff01c20, to eventually
  passing this as 0xbff01c18 to a template. The pointer to the
  std::ios_base object is now off by 8 bytes and this causes the crash.
 
  What happened here? Why does ReadConfigFile() think that the object is
  in a different location?
 
  Any hints on how to track this down?

The ptype command might help to display the object and to see what's
changed.

 The problem is here, we read 0xa8 here from libstdc++6:
 
 (gdb) x/16x $ret0 - 0xc
 0x40437778 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si:
 0x00a8  0x  0x40437b30  0x401b2b96
 0x40437788 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16:
  0x401b2b9e  0xff58  0xff58  0x40437b30
 0x40437798 _ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32:
  0x401b2ba6  0x401b2bae  0x  0x40437834
 
 Then we add this offset to the base location of the object on the
 stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we
 would expect.
 
 It looks like the layout of the object in libstdc++.so.6 has changed,
 my guess is that the changes I made to the locking types in glibc have
 caused the layout to be perturbed.
 
 While I set out the glibc types exactly as before (binary compatible),
 the alignment restrictions were changed subtly.

Excellent debugging!

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

 
 On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno aurel...@aurel32.net wrote:
 
  I confirm, it's what I see in the testsuite log:
 
  | 77
  | __signbitl
  | version status: incompatible
  | GLIBCXX_3.4
  | type: function
  | status: added
 
 If __signbitl is the only failure in the abi_check, then that's easy
 to fix, the testsuite needs to be updated.

The fail is somewhat puzzling because the problem is supposed fixed
in the 4.4 branch.

 With cloog/ppl disabled I still get 7 testsuite failures, so I'll have
 to dig into each failure tommorow and see what's wrong.
 
 ~~~
 Running target unix
 FAIL: abi_check
 FAIL: 26_numerics/complex/13450.cc (test for excess errors)
 UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce
 executable
 FAIL: 26_numerics/complex/pow.cc (test for excess errors)
 UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce 
 executable
 XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test
 for excess errors)
 FAIL: 29_atomics/atomic_flag/clear/1.c execution test
 FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
 FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess 
 errors)
 FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)
 UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation
 failed to produce executable

Try adding --disable-libstdcxx-pch as mentioned earlier in this thread.
This is PR 39355: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355

Good luck in debugging this bug!  I was not able to determine the
actual cause.  It appears GCC's internal data are somewhat corrupt
when the pch header files are generated.  This causes various tests
to ICE when compiled with the pch headers.

The problem appears to have gone away with head.  I don't see it with
hpux.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

 On 08.11.2009 21:38, John David Anglin wrote:
  test results for 4.4.2-1:
  http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
  for 4.4.2-2:
  http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
 
  there are some differences, which are not seen in Dave's build:
  http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
 
  For a release, I wouldn't use cloog/ppl.  It seems to cause some
  loop optimization bugs.
 
 does this really hurt, unless the loop opts are used?

Compare above with
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00812.html

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

 test results for 4.4.2-1:
http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
 for 4.4.2-2:
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
 
 there are some differences, which are not seen in Dave's build:
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html

For a release, I wouldn't use cloog/ppl.  It seems to cause some
loop optimization bugs.  There's also an unresolved issue with
pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
on the 4.4 branch.  The problem seems to be fixed on head.

 there are some parisc scpecific changes:
 
 2009-10-23  John David Anglin  dave.ang...@nrc-cnrc.gc.ca
 
  Backport from mainline:
  2009-08-19  John David Anglin  dave.ang...@nrc-cnrc.gc.ca
 
  * pa.md (reload_inhi, reload_outhi, reload_inqi, reload_outqi): New
  patterns.
  * pa.c (emit_move_sequence): Check if address of operand1 is valid
  for mode mode of operand0 when doing secondary reload for SAR.
 
 2009-10-20  John David Anglin  dave.ang...@nrc-cnrc.gc.ca
 
  Backport from mainline:
  2009-10-15  John David Anglin  dave.ang...@nrc-cnrc.gc.ca
 
  PR target/41702
  * pa.md (casesi): Use sign extended index in call to
  gen_casesi64p.
  (casesi64p): Update pattern to reflect above.

I doubt either of these is the problem.  The latter is specific to
hppa64.  The former is to fix an ICE compiling recent linux kernels.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554574: libstdc++6: apt segfaults on hppa

[John David Anglin]

 On 08.11.2009 21:38, John David Anglin wrote:
  test results for 4.4.2-1:
  http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg01919.html
  for 4.4.2-2:
  http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00351.html
 
  there are some differences, which are not seen in Dave's build:
  http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg00047.html
 
  For a release, I wouldn't use cloog/ppl.  It seems to cause some
  loop optimization bugs.
 
 does this really hurt, unless the loop opts are used?

The testsuite fails that seem related to this are:
FAIL: libgomp.c/omp-loop03.c execution test
FAIL: libgomp.c++/loop-3.C  -O  execution test
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test
FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors)
FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors)

and possibly

FAIL: abi_check

  There's also an unresolved issue with
  pch on the 4.4 branch.  I usually configure with --disable-libstdcxx-pch
  on the 4.4 branch.  The problem seems to be fixed on head.
 
 ok, I'll add this for hppa.

The testsuite fails related to the pch bug are:
FAIL: 26_numerics/complex/13450.cc (test for excess errors)
FAIL: 26_numerics/complex/pow.cc (test for excess errors)

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#427398: Acknowledgement (svn is broken after updating ro

[John David Anglin]

A patch for this problem was posted here:
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031690.html

However, it's likely that the parisc specific code will be removed in
favour of the generic compat code.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

Package: libc6
Version: 2.5-9
Severity: critical
Justification: breaks the whole system

The following command leads to a system crash:

[EMAIL PROTECTED]:~$ df
Filesystem   1K-blocks  Used Available Use% Mounted on

The command hangs after the first line of output is printed.  It
is not possible to kill df, or login with ssh, telnet or the system
console.  The system console prints a continuous stream of the
following error messages:

 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
 PSW: 1110 Not tainted
r00-03  00ff0806ff0f 4036c000 40104edc 
c0601048
r04-07  403d79d4 403d89d4 0002c258 

r08-11  0002a3f4 0002a3f4 0001 

r12-15  0002a3f4  0001 
0002c258
r16-19  0002a3f4 0002a3f4 0002a3f4 

r20-23  012a 4029c000 40357594 
0002c268
r24-27  c0601048 0058 0002c258 
40503fc0
r28-31  403daf60 7c744170 7c744180 
403575e3
sr00-03  000eb800   
000eb800
sr04-07     


IASQ:   IAOQ:  
0004
 IIR: ISR: 000eb800  IOR: 
 CPU:0   CR30: 7c744000 CR31: 404c4000
 ORIG_R28: 40155a7c
 IAOQ[0]: 0x0
 IAOQ[1]: 0x4
 RP(r2): syscall_exit+0x0/0x14

Prior to the libc6 update on June 1, 2008, the system had been running
in a stable manner for several months.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (650, 'testing')
Architecture: hppa (parisc64)

Kernel: Linux 2.6.20-gfb60ab85-dirty
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427398: svn is broken after updating ro libc6 2.5-9

[John David Anglin]

Package: libc6
Version: 2.5-9
Severity: grave
Justification: renders package unusable


After updating to libc6 2.5-9 Friday evening, the svn package is
now broken:

[EMAIL PROTECTED]:~/gnu/gcc-4.3/gcc$ contrib/gcc_update
Updating SVN tree
Ugcc/real.c
Ugcc/real.h
Ugcc/ChangeLog
Ugcc/testsuite/ChangeLog
Dgcc/testsuite/gfortran.dg/allocate_stat_1.f90
Ugcc/config/sh/sh.md
Ugcc/config/m68k/m68k-modes.def
Ugcc/config/m68k/m68k.c
Updated to revision 125296.
svn: Can't read directory '.': Partial results are valid but processing 
is incomplete
Adjusting file timestamps
[EMAIL PROTECTED]:~/gnu/gcc-4.3/gcc$ svn cleanup
svn: Can't read directory 'libgcc/config/ia64/.svn/tmp': Partial results 
are valid but processing is incomplete

If an update is incomplete, svn cleanup can't fix or remove lock
files.  So, a complete new checkout has to be done. 

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (650, 'testing')
Architecture: hppa (parisc64)

Kernel: Linux 2.6.20-gfb60ab85-dirty
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

 Is the libc6 the only thing that you updated? I am using the same libc
 here, paer.debian.org also uses it in the sid chroot, and I am unable to
 reproduce the problem.

No, some other packages were updated.  Here are the most recent
packages in /var/cache/apt/archives:

-rw-r--r-- 1 root root 4088528 May 23 00:17 locales_2.5-9_all.deb
-rw-r--r-- 1 root root  336310 May 23 03:47 ncurses-term_5.6-3_all.deb
-rw-r--r-- 1 root root   12892 May 23 03:47 ncurses-base_5.6-3_all.deb
-rw-r--r-- 1 root root  158668 May 23 12:47 nscd_2.5-9_hppa.deb
-rw-r--r-- 1 root root 4875580 May 23 12:47 libc6_2.5-9_hppa.deb
-rw-r--r-- 1 root root 1435964 May 23 12:47 libc6-pic_2.5-9_hppa.deb
-rw-r--r-- 1 root root 2394486 May 23 12:47 libc6-dev_2.5-9_hppa.deb
-rw-r--r-- 1 root root 5600472 May 23 12:47 libc6-dbg_2.5-9_hppa.deb
-rw-r--r-- 1 root root  244816 May 23 12:47 ncurses-bin_5.6-3_hppa.deb
-rw-r--r-- 1 root root  365522 May 23 12:47 libncursesw5_5.6-3_hppa.deb
-rw-r--r-- 1 root root  344868 May 23 12:47 libncurses5_5.6-3_hppa.deb
-rw-r--r-- 1 root root 2514922 May 29 19:32 binutils_2.17cvs20070426-8_hppa.deb
-rw-r--r-- 1 root root 1222814 May 29 19:32 binutils-hppa64_2.17cvs20070426-8_hp

Running strace df I see:

[EMAIL PROTECTED]:~$ strace df
execve(/bin/df, [df], [/* 19 vars */]) = 0
brk(0)  = 0x2b000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4000
newuname({sys=Linux, node=mx3210, ...}) = 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 21269, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40486000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\2\7..., 512) = 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 1307036, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x402ac000
mmap(0x403e2000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x135000) = 0x403e2000
mmap(0x403ea000, 4508, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x403ea000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40001000
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40002000
munmap(0x40486000, 21269)   = 0
brk(0)  = 0x2b000
brk(0x4c000)= 0x4c000
open(/etc/mtab, O_RDONLY) = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40005000
read(3, /dev/sda3 / ext3 rw,errors=remou..., 4096) = 339
read(3, , 4096)   = 0
close(3)= 0
munmap(0x40005000, 4096)= 0
fstat64(1, {st_mode=0, st_size=4299262263301, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40005000
write(1, Filesystem   1K-blocks  ..., 67Filesystem   
1K-blocks  Used Available Use% Mounted on
) = 67
upeek: ptrace(PTRACE_PEEKUSER,1410,4294967292,0): Input/output error

The console message is different:

 YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
 PSW: 11001011 Not tainted
r00-03  00ff0804ff0b 7fe40180 401023a8 c0572048
r04-07  403e79d4 403e89d4 0002c258 
r08-11  0002a3f4 0002a3f4 0001 
r12-15  0002a3f4  0001 0002c258
r16-19  0002a3f4 0002a3f4 0002a3f4 
r20-23  012a 402ac000 40367594 0002c268
r24-27  c0572048 0058 0002c258 40503fc0
r28-31  7fe40180 7aaa8170 7aaa8180 7aaa8000
sr00-03  00069800   0006c000
sr04-07     

IASQ:   IAOQ:  0004
 IIR: ISR: 00069800  IOR: 
 CPU:0   CR30: 7aaa8000 CR31: 404c4000
 ORIG_R28: 40155a7c
 IAOQ[0]: 0x0
 IAOQ[1]: 0x4
 RP(r2): tracesys_exit+0x0/0x38

Rebooting...
Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

 Is the libc6 the only thing that you updated? I am using the same libc
 here, paer.debian.org also uses it in the sid chroot, and I am unable to
 reproduce the problem.

This is on a PA8800 machine.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

   YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
   PSW: 1110 Not tainted
  r00-03  00ff0806ff0f 4036c000 40104edc 
  c0601048
  r04-07  403d79d4 403d89d4 0002c258 
  
  r08-11  0002a3f4 0002a3f4 0001 
  
  r12-15  0002a3f4  0001 
  0002c258
  r16-19  0002a3f4 0002a3f4 0002a3f4 
  
  r20-23  012a 4029c000 40357594 
  0002c268
  r24-27  c0601048 0058 0002c258 
  40503fc0
  r28-31  403daf60 7c744170 7c744180 
  403575e3
  sr00-03  000eb800   
  000eb800
  sr04-07     
  
  
  IASQ:   IAOQ:  
  0004
   IIR: ISR: 000eb800  IOR: 
   CPU:0   CR30: 7c744000 CR31: 404c4000
   ORIG_R28: 40155a7c
   IAOQ[0]: 0x0
   IAOQ[1]: 0x4
   RP(r2): syscall_exit+0x0/0x14

The above looks to me like a syscall that isn't hooked up.
From syscall.S, I see

LDREGX  %r20(%r19), %r19

/* If this is a sys_rt_sigreturn call, and the signal was received
 * when not in_syscall, then we want to return via syscall_exit_rfi,
 * not syscall_exit.  Signal no. in r20, in_syscall in r25 (see
 * trampoline code in signal.c).
 */
ldi __NR_rt_sigreturn,%r2
comb,=  %r2,%r20,.Lrt_sigreturn
.Lin_syscall:
ldilL%syscall_exit,%r2
be  0(%sr7,%r19)
ldo R%syscall_exit(%r2),%r2

r19 and sr7 are both zero.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

 It looks like you are using a hand built kernel. Do you use the patch to
 disable LWS CAS debugging [1] ?

Yes, but I've been told by Kyle that it's too old.  Syscall 298 was
added in 2.6.21.

I haven't disabled LWS CAS.

My attempts at modifying the kernel to return ENOSYS so far haven't
been successful.  Kyle says binutils is broken, so I need to do this
on a different system.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

  fstat64(3, {st_mode=0, st_size=0, ...}) = 0
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
  0x40005000
  read(3, /dev/sda3 / ext3 rw,errors=remou..., 4096) = 339
  read(3, , 4096)   = 0
  close(3)= 0
  munmap(0x40005000, 4096)= 0
  fstat64(1, {st_mode=0, st_size=4299262263301, ...}) = 0
  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
  0x40005000
  write(1, Filesystem   1K-blocks  ..., 67Filesystem   
  1K-blocks  Used Available Use% Mounted on
  ) = 67
  upeek: ptrace(PTRACE_PEEKUSER,1410,4294967292,0): Input/output error
 
 This strace looks normal or rather this seems to be a different bug. I
 mean I have the same output on my machine when running with strace, but
 df works correctly when not run with strace.

Kyle says df uses statfs64, which was added to 2.6.21... I'm confused
why we're not catching it in syscall.S, I'll need to sit and think a bit.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

 I found really strange that this version of the glibc is using this
 syscall. It has been released 6 months ago, when 2.6.19 was still not
 released... How did you get this syscall number?

It's in register r20 of the register dump that I posted.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

 It really looks like a bug in the kernel.

Yes, see
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031651.html

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427395: libc6: df command causes system crash on parisc

[John David Anglin]

  It really looks like a bug in the kernel.
 
 Yes, see
 http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031651.html

The change posted here fixes the df problem:
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031652.html

So, this bug report can be closed.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342545: [parisc-linux] Re: Bug#342545: qt-x11-free FTBFS

[John David Anglin]

 That would be wonderful if you, or another hppa porter, could track down
 where the bug lies.  libgcc2 is almost certainly the wrong package, since
 nothing should be *using* libgcc2 in a fresh build of qt-x11-free; it may be
 a bug in libgcc4 instead, but I think that's yet to be determined.  In the
 meantime, I think it's best to reassign this back to qt-x11-free.

This might be a nan bug.  There is one GCC nan fix that's only
installed on the trunk:

2006-05-24  John David Anglin  [EMAIL PROTECTED]

PR target/27627
* pa/pa-modes.def: Use mips_single_format, mips_double_format and
mips_quad_format formats instead of ieee_single_format,
ieee_double_format and ieee_quad_format formats, respectively.

However, I think the real bug is here:

  0x40cb2150 in negNan () at tools/qlocale.cpp:131
  131 *((const double *) le_neg_nan_bytes));

PA-RISC requires strict alignment and it's highly likely that
the pointer le_neg_nan_bytes isn't aligned to an eight byte
boundary.  You could see the faulting insn by disassembling
around 0x40cb2150 to be sure.  The nan problem fixed by the
above change would cause a SIGFPE instead of a SIGBUS.

I'm fairly certain we have a bug in handling unaligned fixups
for doubles in the kernel.  This caused a problem for libffi.
This depends on whether the kernel is 32/64 bits.

As Kyle pointed out, unaligned fixups by the kernel are expensive
and they should be avoided.  tools/qlocale.cpp appears to be a
qt-x11-free routine, so I agree that the reassignment was correct.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342545: [parisc-linux] Re: Bug#342545: qt-x11-free FTBFS

[John David Anglin]

Steve,

 This might be a nan bug.  There is one GCC nan fix that's only
 installed on the trunk:
 
 2006-05-24  John David Anglin  [EMAIL PROTECTED]
 
   PR target/27627
   * pa/pa-modes.def: Use mips_single_format, mips_double_format and
   mips_quad_format formats instead of ieee_single_format,
   ieee_double_format and ieee_quad_format formats, respectively.

Just saw your patch.  Watch out, there are at least two different
representations for nans.  In GCC, they are called mips and ieee.
However, as far as I can tell, PA-RISC used the mips format before
mips.  Both formats are complient with the original IEEE standard,
so it's also a bit of a misnomer to call the other format the IEEE
format.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

[John David Anglin]

 Ok, coming back to the question of the system compiler on hppa for
 etch. Assuming that hppa does want to do that:
 
 - is glibc buildable with gcc-4.1 on hppa?

As far as I know, there's no new problems using 4.1 instead of 4.0.  See
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028894.html
and test results for a gcc 4.2.0 build using this glibc build
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028918.html

 - libstdc++6 would need to conflict with libgcc2, which seems to be
   doable, but then rules out g++-3.4 and g++-4.0 as a fallback
   solution, where g++-4.1 fails.

True.

 - is libffi hit by the ABI change as well?

No.  It's not affected because it doesn't support complex types.

I have one libffi fix that's not yet in 4.2.0 that fixes the remaining
Java testsuite failures.  I haven't tested a backport to 4.1.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching

[John David Anglin]

 Er, no; we're talking about official Debian packages here, and the
 libstdc++.so.6 in Debian is now from gcc-4.1.  The problem is precisely that
 GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
 in the double libgcc_s problem.

Then, you must build *eveything* for hppa with gcc-4.1 or later.

Unfortunately, there's an ABI break.  Mixing libraries compiled with
4.0 or earlier with libraries compiled with 4.1 or later is just going
to cause unnecessary problems.   3.3 uses libstdc++.so.5, so you
avoid the double libgcc_s problem building GMP.  However, you still
have the ABI change affecting the passing and return of complex types.

At a fundamental level, libstdc++.so.6, libgfortran.so.1.0.0 and any
other gcc libraries built with 4.1 or later need glibc built with 4.1
to function correctly because of the various complex functions in
the math library.

I think there's a dynamic loader bug here as well.  I'm just
guessing but I think the double libgcc_s problem causes a problem
with the handling of .eh_frame data.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

 Is this acutally decided?  Is it likely to happen soon, or should I
 build GMP with gcc 3.3 (which doesn't exhibit the problem) in the
 short term?

For now, I suggest that you remove gcc-4.1 from your build system.
Then, GMP should build fine with 4.0.  You might have to reinstall
4.0.

As far as I can tell, EH support breaks when two different versions
of libgcc_s are linked into an application.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

 On Sat, Apr 22, 2006 at 10:00:04AM +0200, Matthias Klose wrote:
  $ ldd a.out
  libstdc++.so.6 =3D /usr/lib/libstdc++.so.6 (0x40575000)
  libm.so.6 =3D /lib/libm.so.6 (0x4046e000)
  libgcc_s.so.2 =3D /lib/libgcc_s.so.2 (0x40068000)
  libc.so.6 =3D /lib/libc.so.6 (0x4074b000)
  libgcc_s.so.4 =3D /lib/libgcc_s.so.4 (0x40015000)
  /lib/ld.so.1 (0x400e1000)
 
  We end up with both libgcc_s.so.2 and libgcc_s.so.4 linked.  Is there
  a solution other than making gcc-4.1/g++-4.1 the default and
  rebuilding the libstdc++6 dependent packages with binary NMU's?
 
 I guess having gcc-4.0 link against libgcc4 is out of the question?

Doing so is not a good idea, but it's only going to break numeric
applications using complex numbers and possibly vectors.

The calling conventions for passing complex values was changed between
4.0 and 4.1 when it was discovered that it didn't conform to the runtime
documentation.  Support for complex and vector objects was added to GCC
some time ago.  However noone noticed that these values weren't being
passed correctly...

The change affects the routines __muldc3, __mulsc3, __divdc3 and __divsc3
in libgcc_s.  It also affects any package/library using complex numbers,
including glibc since the registers used for passing the first few
arguments and the return value have changed.  Particularly, complex
floats are no longer passed in the floating registers.

I think the approach suggested by Matthias is ultimately the only
viable solution but the impact is broader than the libstdc++6 dependent
packages.  The situation is similar to that when DWARF EH support was
introduced.  The only other option that I can see is to delay 4.1.
However, I would like 4.1 to become the default.

For the most part, the passing of complex values in 4.0 and earlier
is internally self-consistent (there's a minor incompatibility between
PA 1.0 code and PA 1.1 code due to the fact that the left and right
halves of floating-point registers are not independently accessible
when generating PA 1.0 code).

I recognized that this was going to cause pain, and brought the matter
up for discussion on the parisc-linux list a few months ago.  There
wasn't much in the way of comments for or against.  In the end, I
decided it was probably better to make the change in 4.1 and let time
smooth over the difficulties.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

  [EMAIL PROTECTED]:~/gmp-4.2.dfsg/tests/cxx$ g++ -Wall test-throw.cc  
  ./a.out
  /usr/bin/ld: warning: libgcc_s.so.4, needed by 
  /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so, may conflict with 
  libgcc_s.so.2

I'm puzzled about this.  It seems like libstdc++ for GCC 4.0.3 was
built using GCC 4.1 or latter.  In my 4.0.3 build, I see:

[EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd 
libstdc++.so
libm.so.6 = /lib/libm.so.6 (0x40643000)
libgcc_s.so.2 = /lib/libgcc_s.so.2 (0x4034a000)
libc.so.6 = /lib/libc.so.6 (0x40a57000)
/lib/ld.so.1 (0x41252000)

But:

[EMAIL PROTECTED]:~/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs$ ldd 
/usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so
libm.so.6 = /lib/libm.so.6 (0x40243000)
libgcc_s.so.4 = /lib/libgcc_s.so.4 (0x40746000)
libc.so.6 = /lib/libc.so.6 (0x40a57000)
/lib/ld.so.1 (0x41252000)

You need to build 4.0.3 and associated libraries with 4.0.3.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#364231: [parisc-linux] Re: Bug#364231: exception catching broken on HPPA

[John David Anglin]

 Yes, we do, but
 
 $ ls -l /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so
 lrwxr-xr-x 1 root root 23 Apr  6 02:08 
 /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so - ../../../libstdc++.so.6

Oh, I was thinking there were separate libraries for each GCC version.
I've had to live with this for some time using hpux.

 we can only have one libstdc++.so.6 installed. that's currently the
 library from 4.1. So maybe we need to bump the soversion of libstdc++
 on hppa?

To me, that seems too complicated.  It's not just libstdc++.so.6 but
potentially every shared library built with 4.1 or later needs a bump.

The simplest approach is to make GCC 4.1 the default and remove 4.0
and earlier.  Then, gradually rebuild everthing with 4.1.  There have
been reports on the gcc list that this has been reasonably successful.

I imagine that some will complain about losing their favorite GCC
version.  The issues with C are less severe because of the libgcc_s
version bump.  Old versions will generate code that's incompatible
with the complex math routines in libc6 but they should otherwise
work.  I think for kernel building it's useful to keep old versions,
but not for much else.  Thus, the compromise may be to keep old
versions of C and drop all the other languages.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#341675: [parisc-linux] Re: qt-x11-free build fails

[John David Anglin]

 On Sat, Jan 07, 2006 at 01:05:11AM -0800, Steve Langasek wrote:
  Grant, thank you for your work to date on this bug.  (BTW, it would be
  helpful if you would follow up to bug #342545 on libgcc2, instead of bug
  #341675 which is filed against just one of the many packages affected by
  it).

There isn't a lot of info in #342545.  However, I suspect from the
following comment

 It would be nice if somebody fluent with hppa assembly can tell us if 

   fldw -10(,sp),fr23

that this is the same bug as reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#341675: [parisc-linux] Re: qt-x11-free build fails

[John David Anglin]

 There isn't a lot of info in #342545.  However, I suspect from the
 following comment
 
  It would be nice if somebody fluent with hppa assembly can tell us if 
 
fldw -10(,sp),fr23
 
 that this is the same bug as reported here:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754.

Changed my mind based on the discussion in
http://lists.debian.org/debian-hppa/2006/01/msg1.html.  The only
way that the above instruction can cause an invalid exception is

  The current instruction is a load of the destination register of
  a pending, trapping instruction (see page 10-5 of arch, delayed
  traps).

The instruction can cause the usual memory faults (i.e., check value
in sp).  In either case, the real problem is somewhere else.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329888: [parisc-linux] binutils breaks hppa kernel build,

[John David Anglin]

 binutils-2.15 has this in include/opcodes/hppa.h:
 { fdc,0x04001280, 0xfc003fdf, cZx(s,b), pa10, 0},
 { fdc,0x04001280, 0xfc003fdf, cZx(b), pa10, 0},
 { fic,0x04000280, 0xfc001fdf, cZx(S,b), pa10, 0},
 { fic,0x04000280, 0xfc001fdf, cZx(b), pa10, 0},

The last fic opcode entry is wrong.  It's using the wrong
instruction format, the mask is wrong, pa10 is wrong, etc.

 And the binutils_2.16.1cvs20050902 version has only:
 { fdc,0x04001280, 0xfc00ffdf, cZx(b), pa10, 0},
 { fdc,0x04001280, 0xfc003fdf, cZx(s,b), pa10, 0},
 { fic,0x04000280, 0xfc001fdf, cZx(S,b), pa10, 0},

Yes, I deleted the entry because there isn't implicit space
register selection for 'S' instructions.

 The order of the with 's' vs without 's' was switched and
 in the process dropped one fic line.

Changing the order of with 's' vs without 's' was intentional.
It generates better disassembly.  Give the new objdump a try
and you will see the difference.

 Can binutils maintainer/folks please just add it back
 in the new location?

We need a new pa20 format 24 entry.

 Is the fix obvious enough or is a patch necessary?

A patch is needed.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329888: [parisc-linux] binutils breaks hppa kernel build,

[John David Anglin]

  binutils-2.15 has this in include/opcodes/hppa.h:
  { fdc,0x04001280, 0xfc003fdf, cZx(s,b), pa10, 0},
  { fdc,0x04001280, 0xfc003fdf, cZx(b), pa10, 0},
  { fic,0x04000280, 0xfc001fdf, cZx(S,b), pa10, 0},
  { fic,0x04000280, 0xfc001fdf, cZx(b), pa10, 0},
 
 The last fic opcode entry is wrong.  It's using the wrong
 instruction format, the mask is wrong, pa10 is wrong, etc.

The enclosed patch against binutils head adds the missing fic
entry.  I also noticed that we were missing a pa20 im5 variant for
fdc.  This builds and checks with no regressions.  However,
the new entries aren't really tested.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Index: hppa.h
===
RCS file: /cvs/src/src/include/opcode/hppa.h,v
retrieving revision 1.59
diff -u -3 -p -r1.59 hppa.h
--- hppa.h  3 Aug 2005 15:08:52 -   1.59
+++ hppa.h  25 Sep 2005 01:58:35 -
@@ -755,6 +755,9 @@ static const struct pa_opcode pa_opcodes
 { pdc,   0x04001380, 0xfc003fdf, cZx(s,b), pa10, 0},
 { fdc,   0x04001280, 0xfc00ffdf, cZx(b), pa10, 0},
 { fdc,   0x04001280, 0xfc003fdf, cZx(s,b), pa10, 0},
+{ fdc,   0x04003280, 0xfc00, 5(b), pa20, FLAG_STRICT},
+{ fdc,   0x04003280, 0xfc003fff, 5(s,b), pa20, FLAG_STRICT},
+{ fic,   0x040013c0, 0xfc00dfdf, cZx(b), pa20, FLAG_STRICT},
 { fic,   0x04000280, 0xfc001fdf, cZx(S,b), pa10, 0},
 { fdce,  0x040012c0, 0xfc00ffdf, cZx(b), pa10, 0},
 { fdce,  0x040012c0, 0xfc003fdf, cZx(s,b), pa10, 0},


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329888: [parisc-linux] binutils breaks hppa kernel build,

[John David Anglin]

 On Sat, Sep 24, 2005 at 09:27:22PM -0400, John David Anglin wrote:
  The last fic opcode entry is wrong.  It's using the wrong
  instruction format, the mask is wrong, pa10 is wrong, etc.
 
 I don't think we realised this until now.  I suspect we've been
 silently emitting bad code up until this point, and given that it's
 in flush_kernel_icache_page, maybe it explains some of our occasional
 crashes.
 
 The code was previously:
 
 fic,m   %r23(%r26)

I've committed a fix to binutils head.  The above should now be
accepted when generating PA 2.0 code.  However, I'd probably
avoid using this feature for awhile.  It looks like the bug has
been present since ~ 1996.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#321785: fakeroot: segfaults on [hppa]

[John David Anglin]

  no, it's not fakeroot, it's make segfaulting ...
 [...]
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 16384 (LWP 16911)]
  0x4091fd20 in __canonicalize_funcptr_for_compare () from 
  /lib/libpthread.so.0
  (gdb) bt
  #0  0x4091fd20 in __canonicalize_funcptr_for_compare ()
 from /lib/libpthread.so.0
  #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
  #2  0x405cc950 in sigaction () from /lib/libc.so.6
  #3  0x405cc748 in ssignal () from /lib/libc.so.6
  #4  0x0001d690 in main ()
  (gdb)
 
 Confirmed. We are passing a function pointer with a value of -2 into
 __cffc, which should not happen...

I've posted a candidate gcc fix here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00923.html

As I mentioned earlier today to Randolph, I think there should possibly
be a pa specific implementation of sigaction that avoids doing function
pointer canonicalization.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#321785: fakeroot: segfaults on [hppa]

[John David Anglin]

 #1  0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8, 
 oact=0xc0241f50)
  at signals.c:106
 106   if (old == SIG_IGN || old == SIG_DFL || old == SIG_ERR)
 (gdb) print old
 Address requested for identifier old which is in register $r11
 (gdb) print /x $r11
 $6 = 0x0
 (gdb) print /x $pc
 $7 = 0x406d7424
 (gdb) disassemble $pc-16 $pc+4
 Dump of assembler code from 0x406d7414 to 0x406d7428:
 0x406d7414 __pthread_sigaction+252:   stw r20,-138(,sp)
 0x406d7418 __pthread_sigaction+256:   copy r19,r4
 0x406d741c __pthread_sigaction+260:   b,l 0x406dbcd8 
 __canonicalize_funcptr_for_compare,rp
 0x406d7420 __pthread_sigaction+264:   ldo -2(r11),r26
 0x406d7424 __pthread_sigaction+268:   copy r4,r19
 End of assembler dump.
 (gdb)
 
 Why is it doing that ldo -2(r11),r26 ?

I would have thought that old (r11) would have just been copied to
r26.  Could you send preprocessed source and compilation details?

The handling of function pointers in 4.0 branch was broken prior to
this change:

2005-07-02  Jeff Law  [EMAIL PROTECTED]

* tree-ssa-dom.c (find_equivalent_equality_comparison): Do not
a eliminate type conversion which feeds an equality comparison
if the original type or either operand in the comparison is a
function pointer.

This change is in 4.0.1.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#321785: fakeroot: segfaults on [hppa]

[John David Anglin]

  no, it's not fakeroot, it's make segfaulting ...
 [...]
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 16384 (LWP 16911)]
  0x4091fd20 in __canonicalize_funcptr_for_compare () from 
  /lib/libpthread.so.0
  (gdb) bt
  #0  0x4091fd20 in __canonicalize_funcptr_for_compare ()
 from /lib/libpthread.so.0
  #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
  #2  0x405cc950 in sigaction () from /lib/libc.so.6
  #3  0x405cc748 in ssignal () from /lib/libc.so.6
  #4  0x0001d690 in main ()
  (gdb)

GSIGNAL(3) Linux Programmer's ManualGSIGNAL(3)

NAME
   gsignal, ssignal - software signal facility

SYNOPSIS
   #include signal.h

   typedef void (*sighandler_t)(int);

   int gsignal(signum);

   sighandler_t ssignal(int signum, sighandler_t action);

DESCRIPTION
   Don't  use  these  functions under Linux.  Due to a historical mistake,
   under Linux these functions  are  aliases  for  raise()  and  signal(),
   respectively.

   ...

CONFORMING TO
   SVID2, XPG2.  These functions are available  under  AIX,  DG-UX,  HPUX,
   SCO, Solaris, Tru64.  They are called obsolete under most of these sys-
   tems, and are broken under Linux libc and  glibc.   Some  systems  also
   have gsignal_r() and ssignal_r().

I'm guessing that ssignal is called with action -2.  I have no idea
what that's supposed to do.  __cffc accepts small positive function
pointer addresses and -1 as special.  It doesn't attempt to canonicalize
them.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#321785: fakeroot: segfaults on [hppa]

[John David Anglin]

  no, it's not fakeroot, it's make segfaulting ...
 [...]
  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 16384 (LWP 16911)]
  0x4091fd20 in __canonicalize_funcptr_for_compare () from 
  /lib/libpthread.so.0
  (gdb) bt
  #0  0x4091fd20 in __canonicalize_funcptr_for_compare ()
 from /lib/libpthread.so.0
  #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
  #2  0x405cc950 in sigaction () from /lib/libc.so.6
  #3  0x405cc748 in ssignal () from /lib/libc.so.6
  #4  0x0001d690 in main ()
  (gdb)
 
 Confirmed. We are passing a function pointer with a value of -2 into
 __cffc, which should not happen...

Is -2 a special signal number?

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#321785: fakeroot: segfaults on [hppa]

[John David Anglin]

 Confirmed. We are passing a function pointer with a value of -2 into
 __cffc, which should not happen...
  
  
  Is -2 a special signal number?
 
 I don't think so. in any case, others have observed that if they use an 
 older glibc, this problem does not happen.

Not sure this is related, but your put_user kernel patch fixed
some c++ issues.  There are also issues with the alignment of
alternate signal stacks.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]