Re: kde4libs vs qt4
On Mon, Jun 16, 2008 at 5:29 PM, Helge Deller <[EMAIL PROTECTED]> wrote:
> I then attached to it with gdb and got this backtrace:
>
> #0 0x40625d0c in q_atomic_lock (lock=0x5d300) at
> arch/parisc/qatomic_parisc.cpp:97
> #1 0x407cf8d4 in QEventDispatcherGlib::wakeUp (this=)
> at ../../include/QtCore/../../src/corelib/arch/qatomic_parisc.h:115
> #2 0x4078b954 in QCoreApplication::postEvent (receiver=0x781e0,
> event=0x5f140, priority=0)
> at kernel/qcoreapplication.cpp:1020
> #3 0x40797e84 in QMetaObject::invokeMethod (obj=0x781e0, member= optimized out>, type=Qt::QueuedConnect
> ion, ret=
> { = {_data = 0x0, _name = 0x0}, },
> val0={_data = 0x0, _name = 0x0}, val1=
> {_data = 0x0, _name = 0x0}, val2={_data = 0x0, _name = 0x0}, val3={_data =
> 0x0, _name = 0x0}, val4=
>{_data = 0x0, _name = 0x0}, val5={_data = 0x0, _name = 0x0}, val6={_data
> = 0x0, _name = 0x0}, val7=
> {_data = 0x0, _name = 0x0}, val8={_data = 0x0, _name = 0x0},
> val9={_data = 0x0, _name = 0x0})
> at kernel/qmetaobject.cpp:1009
> #4 0x406d18fc in QBuffer::writeData (this=0x5d300, data=0xfb676a58
> "\003gj\b", len=1)
> at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs.h:371
> #5 0x406f3be8 in QIODevice::write (this=0x781e0, data=0xfb676a58
> "\003gj\b", maxSize=1) at io/qiodevice.cpp:1
> 265
> #6 0x406f3fbc in QIODevicePrivate::putCharHelper (this= out>, c=3 '\003') at io/qiodevice.cpp
> :1327
> #7 0x406f0514 in QIODevice::putChar (this=, c=0 '\0')
> at io/qiodevice.cpp:1319
> #8 0x406d2db8 in QDataStream::operator<< (this=0xfb676804, i=0 '\0') at
> io/qdatastream.cpp:912
> #9 0x000272ec in TranslatorMessage::write (this=0x72e30,
> [EMAIL PROTECTED], strip=false, prefix=TranslatorMe
> ssage::Hash)
> at ../../../include/QtCore/../../src/corelib/io/qdatastream.h:219
> #10 0x00028c7c in Translator::squeeze (this=0xfb6765e4,
> mode=Translator::Everything) at ../shared/translator.c
> pp:240
> #11 0x000294d4 in Translator::save (this=0x5d300, iod=0xfb6764cc,
> mode=Translator::Everything)
> at ../shared/translator.cpp:165
> #12 0x00021238 in MetaTranslator::release (this=0xfb676324, iod=0xfb6764cc,
> verbose=false, ignoreUnfinished=
> false,
> mode=Translator::Everything) at ../shared/metatranslator.cpp:601
>
> So, it's hanging in my new parisc-specific function "q_atomic_lock()", and I
> found, that the lock was in "Locked" state.
Is the entire set of lock words zero?
> My question are:
> - Have you seen something similar before? Does another platform maybe had
> similar problems?
>
> - HPPA/PARISC is specific, which means, that locks are locked when the
> lock-variable is zero, while they are unlocked when it's "-1" (or non-zero).
> For me it seems that this specific lock (I don't even know yet which one)
> has not been initially initialized with "-1" and as such the lock starts in
> locked-state, which is why the build then hangs from the beginning.
I have been fixing this problem for *years* in both glibc, gcc, and
other packages.
The problem:
1. Memory is malloc'd.
2. Initializer for mutex is used correctly.
3. Incorrect memset clears the entire structure.
This goes unnoticed on x86, but breaks hppa.
This is one of the benefits of the kernel helpers implementation, in
that we get the same behaviour as x86 :-)
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
On Monday 16 June 2008, Helge Deller wrote: > Hi Sune, > > attached is the latest draft of my patch against qt4-X11. > > It successfully ran both of the tests you mentioned (although I had to > > replace the "load(qttest_p4)" by "CONFIG += qtestlib"): > > http://chaos.troll.no/~bhughes/qatomicint/ > > http://chaos.troll.no/~bhughes/qatomicpointer/ so far so good. > Although everything seems good so far, I still ran into a problem where > I might need your help. Maybe you have seen it already or have an idea? > > The problem is, that during dpkg-buildpackage the build just stops. > Here is the log: > ... > dh_installdirs -plibqtcore4 > /mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/bin/lrelease-qt4 > debian/translations/qt_ca.ts \ > -qm > /mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/debian/tmp//usr/share/qt4/translations/qt >_ca.qm Updating > '/mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/debian/tmp//usr/share/qt4/translations/q >t_ca.qm'... > > > The build hangs when running this program: > /mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/bin/lrelease-qt4 > debian/translations/qt_ca.ts -qm /mnt/sdb4/cvs/qt4-3/qt4-x1 > 1-4.4.0/debian/tmp//usr/share/qt4/translations/qt_ca.qm > > So, it's hanging in my new parisc-specific function "q_atomic_lock()", > and I found, that the lock was in "Locked" state. > > My question are: > - Have you seen something similar before? Does another platform maybe > had similar problems? > > - HPPA/PARISC is specific, which means, that locks are locked when the > lock-variable is zero, while they are unlocked when it's "-1" (or > non-zero). For me it seems that this specific lock (I don't even know > yet which one) has not been initially initialized with "-1" and as such > the lock starts in locked-state, which is why the build then hangs from > the beginning. > > Any ideas? My best idea right now is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433031 but that's al I got sofar. /Sune -- Do you know how may I do for getting access over a serial password? From Word you should close the file on the mousepad for digiting from a level-2 2D menu. signature.asc Description: This is a digitally signed message part.
Re: kde4libs vs qt4
Hi Sune,
attached is the latest draft of my patch against qt4-X11.
It successfully ran both of the tests you mentioned (although I had to
replace the "load(qttest_p4)" by "CONFIG += qtestlib"):
http://chaos.troll.no/~bhughes/qatomicint/
http://chaos.troll.no/~bhughes/qatomicpointer/
Although everything seems good so far, I still ran into a problem where
I might need your help. Maybe you have seen it already or have an idea?
The problem is, that during dpkg-buildpackage the build just stops.
Here is the log:
...
dh_installdirs -plibqtcore4
/mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/bin/lrelease-qt4
debian/translations/qt_ca.ts \
-qm
/mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/debian/tmp//usr/share/qt4/translations/qt_ca.qm
Updating
'/mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/debian/tmp//usr/share/qt4/translations/qt_ca.qm'...
The build hangs when running this program:
/mnt/sdb4/cvs/qt4-3/qt4-x11-4.4.0/bin/lrelease-qt4
debian/translations/qt_ca.ts -qm /mnt/sdb4/cvs/qt4-3/qt4-x1
1-4.4.0/debian/tmp//usr/share/qt4/translations/qt_ca.qm
I then attached to it with gdb and got this backtrace:
#0 0x40625d0c in q_atomic_lock (lock=0x5d300) at
arch/parisc/qatomic_parisc.cpp:97
#1 0x407cf8d4 in QEventDispatcherGlib::wakeUp (this=)
at ../../include/QtCore/../../src/corelib/arch/qatomic_parisc.h:115
#2 0x4078b954 in QCoreApplication::postEvent (receiver=0x781e0,
event=0x5f140, priority=0)
at kernel/qcoreapplication.cpp:1020
#3 0x40797e84 in QMetaObject::invokeMethod (obj=0x781e0, member=optimized out>, type=Qt::QueuedConnect
ion, ret=
{ = {_data = 0x0, _name = 0x0}, },
val0={_data = 0x0, _name = 0x0}, val1=
{_data = 0x0, _name = 0x0}, val2={_data = 0x0, _name = 0x0}, val3={_data
= 0x0, _name = 0x0}, val4=
{_data = 0x0, _name = 0x0}, val5={_data = 0x0, _name = 0x0},
val6={_data = 0x0, _name = 0x0}, val7=
{_data = 0x0, _name = 0x0}, val8={_data = 0x0, _name = 0x0},
val9={_data = 0x0, _name = 0x0})
at kernel/qmetaobject.cpp:1009
#4 0x406d18fc in QBuffer::writeData (this=0x5d300, data=0xfb676a58
"\003gj\b", len=1)
at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs.h:371
#5 0x406f3be8 in QIODevice::write (this=0x781e0, data=0xfb676a58
"\003gj\b", maxSize=1) at io/qiodevice.cpp:1
265
#6 0x406f3fbc in QIODevicePrivate::putCharHelper (this=out>, c=3 '\003') at io/qiodevice.cpp
:1327
#7 0x406f0514 in QIODevice::putChar (this=, c=0
'\0') at io/qiodevice.cpp:1319
#8 0x406d2db8 in QDataStream::operator<< (this=0xfb676804, i=0 '\0') at
io/qdatastream.cpp:912
#9 0x000272ec in TranslatorMessage::write (this=0x72e30,
[EMAIL PROTECTED], strip=false, prefix=TranslatorMe
ssage::Hash)
at ../../../include/QtCore/../../src/corelib/io/qdatastream.h:219
#10 0x00028c7c in Translator::squeeze (this=0xfb6765e4,
mode=Translator::Everything) at ../shared/translator.c
pp:240
#11 0x000294d4 in Translator::save (this=0x5d300, iod=0xfb6764cc,
mode=Translator::Everything)
at ../shared/translator.cpp:165
#12 0x00021238 in MetaTranslator::release (this=0xfb676324,
iod=0xfb6764cc, verbose=false, ignoreUnfinished=
false,
mode=Translator::Everything) at ../shared/metatranslator.cpp:601
So, it's hanging in my new parisc-specific function "q_atomic_lock()",
and I found, that the lock was in "Locked" state.
My question are:
- Have you seen something similar before? Does another platform maybe
had similar problems?
- HPPA/PARISC is specific, which means, that locks are locked when the
lock-variable is zero, while they are unlocked when it's "-1" (or
non-zero). For me it seems that this specific lock (I don't even know
yet which one) has not been initially initialized with "-1" and as such
the lock starts in locked-state, which is why the build then hangs from
the beginning.
Any ideas?
Best regards,
Helge
diff -up ./debian/patches/series.org ./debian/patches/series
--- ./debian/patches/series.org 2008-06-14 16:54:47.0 +0200
+++ ./debian/patches/series 2008-06-14 16:55:47.0 +0200
@@ -33,7 +33,8 @@
41_disable_opengl_visibility.diff
50_kfreebsd_build_fix.diff
60_m68k_inotify_fix.diff
-70_hppa_ldcw_fix.diff
+#70_hppa_ldcw_fix.diff
+70_hppa_ldcw_fix_2.diff
71_hppa_unaligned_access_fix_458133.diff
72_generic_arch_atomic_header_fix.diff
73_from4.4.1_no__when_ipv6_disabled.diff
diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 2008-06-14 17:19:35.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff 2008-06-14 17:21:22.0 +0200
@@ -54,3 +54,16 @@ Reported to trolltech as N180631 - and t
UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
+@@ -2385,6 +2385,12 @@ if [ -z "${HOST_ARCH}" ]; then
+ fi
+ HOST_ARCH=sparc
+
Re: kde4libs vs qt4
On Wednesday 11 June 2008, Helge Deller wrote: > Hello Sune, > > Sune Vuorela wrote: > > I now hacked a bit and got stuff working on one of those cluster > > machines. http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4- > > x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=file&rev=0&s > >c=0 > > > > This isn't the "real solution" though. > > > > Qt4 has arch specific code for most archs (and a "generic" arch mostly > > used for bootstrapping of Qt), but no arch for linux/hppa, so we use the > > "generic" arch here. > > > > The real solution involves some hppa assembler (which is way out of my > > league). There is a patch in the package by lamont about patching the > > hpux code, but I couldn't get taht to work with my quick tests. > > Attached are the basic pieces which should get it working with the > qt4-x11_4.4.0-3 source package. My machine is still compiling, but it > seems OK so far... Okay. > This piece makes configure detect hppa as a parisc-architecture: > > diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org > ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff > --- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 2008-06-11 > 23:34:12.0 +0200 > +++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff 2008-06-11 > 23:34:23.0 +0200 > @@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t > + UNAME_MACHINE="armv5tel" > + ;; > + hppa) > -+UNAME_MACHINE="parisc64" > ++UNAME_MACHINE="parisc" > + ;; > + hurd-i386) > + UNAME_MACHINE="i686-AT386" > This part is definately wrong, as this gets hardcoded into the binaries and changes here will make all modules refuse to load. I think doing something around line 2333 of configure might work. > Full patch attached as well, just in case my mailer breaks the lines. > Could you test it ? Do you need more ? There is some tests here: http://chaos.troll.no/~bhughes/qatomicint/ http://chaos.troll.no/~bhughes/qatomicpointer/ and trying to build kde4libs (experimental) against it might also show something. I would like if some of you hppa people could test it a bit. I don't feel like throwing it at the debian buildds before that, as it takes a couple of days on some archs to build. /Sune -- I'm not able to reset the GPU, how does it work? The point is that you neither have to insert a TCP/IP provider on a head of a bus of the Ultra-wide GUI, nor can ever digit from the 4-bit IDE prompt, so that from Photoshop or from the tools within Outlook 93 you should ping the front-side bus for saving on a clock to a controller over the command prompt. signature.asc Description: This is a digitally signed message part.
Re: kde4libs vs qt4
On Wed, Jun 11, 2008 at 11:54:49PM +0200, Helge Deller wrote:
> Hello Sune,
...
> Attached are the basic pieces which should get it working with the
> qt4-x11_4.4.0-3 source package. My machine is still compiling, but it seems
> OK so far...
>
> First of all, I reused the "parisc" architecture code from the Trolls.
> hppa and parisc are the same architectures, so why introduce something new?
I agree with this approach.
I also want to remind that Carlos once was inspired to document how
futexes would (have been?) be implemented in parisc:
http://wiki.parisc-linux.org/FutexImplementation
Not sure it's useful here but might be worth reviewing once.
...
> And this part replaces the debian patch "70_hppa_ldcw_fix.diff".
> Maybe you could name this one "71_hppa_ldcw_fix.diff" and add it to the
> to-be-applied patches list?
> Benefit of my version is, that the q_ldcw() assembler statement will be
> inlined any will perform better than a call to an external funtion.
...
> diff -up ./src/corelib/arch/parisc/qatomic_parisc.cpp.org
> ./src/corelib/arch/parisc/qatomic_parisc.cpp
> --- ./src/corelib/arch/parisc/qatomic_parisc.cpp.org 2008-06-10
> 00:02:32.0 +0200
> +++ ./src/corelib/arch/parisc/qatomic_parisc.cpp 2008-06-10
> 00:09:54.0 +0200
> @@ -72,7 +72,21 @@ static int *align16(int *lock)
>
> extern "C" {
>
> +#if defined(Q_OS_LINUX)
> +#if defined(__LP64__)
> + #define __LDCW "ldcw,co"
> +#else
> + #define __LDCW "ldcw"
> +#endif
Some historical discussion around ",co" completer:
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2003-February/032223.html
ISTR ",co" wasn't actually useful since no parisc CPU was ever made with
weakly ordered memory.
> +#define q_ldcw(addr) ({ \
> + unsigned __ret; \
> + __asm__ __volatile__(__LDCW " 0(%1),%0" \
> + : "=r" (__ret) : "r" (addr)); \
> + __ret; \
And I think you will also need "memory" added to the asm:
http://lists.parisc-linux.org/pipermail/parisc-linux/2004-September/049068.html
or at least the equivalent of mb()and as that thread shows, I had trouble
with
it then too.
Unlock side of things also seems relevant:
http://lists.parisc-linux.org/pipermail/parisc-linux-cvs/2004-August/034445.html
hth,
grant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
On Tue, Jun 10, 2008 at 09:27:41AM -0400, Carlos O'Donell wrote: ... > Unfortunately I think you're approach won't work due to the alignment > requirements placed on ldcw? It has to be 16-byte aligned according to > the architecture docs. I'll remind of the comments added to our asm/system.h: 168 /* From: "Jim Hull" 169I've attached a summary of the change, but basically, for PA 2.0, as 170long as the ",CO" (coherent operation) completer is specified, then the 17116-byte alignment requirement for ldcw and ldcd is relaxed, and instead 172they only require "natural" alignment (4-byte for ldcw, 8-byte for 173ldcd). */ So the alignment requirement is 16 only for PA1.x binaries. hth, grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
Hello Sune,
Sune Vuorela wrote:
I now hacked a bit and got stuff working on one of those cluster machines.
http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4-
x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=file&rev=0&sc=0
This isn't the "real solution" though.
Qt4 has arch specific code for most archs (and a "generic" arch mostly used
for bootstrapping of Qt), but no arch for linux/hppa, so we use the "generic"
arch here.
The real solution involves some hppa assembler (which is way out of my
league). There is a patch in the package by lamont about patching the hpux
code, but I couldn't get taht to work with my quick tests.
Attached are the basic pieces which should get it working with the
qt4-x11_4.4.0-3 source package. My machine is still compiling, but it
seems OK so far...
First of all, I reused the "parisc" architecture code from the Trolls.
hppa and parisc are the same architectures, so why introduce something
new? Furthermore the Qt code base has lots of "#ifdef QT_ARCH_PARISC",
e.g. in src/corelib/thread/qbasicatomic.h, which would need to be
duplicated for hppa.
The nice effect is, that this way the parisc-atomic-headers will be used
instead of the generic-locking-headers and it should fix a lot of
following problems, e.g. with KDE.
This piece makes configure detect hppa as a parisc-architecture:
diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org
./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 2008-06-11
23:34:12.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff 2008-06-11
23:34:23.0 +0200
@@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t
+ UNAME_MACHINE="armv5tel"
+ ;;
+ hppa)
-+ UNAME_MACHINE="parisc64"
++ UNAME_MACHINE="parisc"
+ ;;
+ hurd-i386)
+ UNAME_MACHINE="i686-AT386"
Not sure if it's needed, but it doesn't hurts either:
(I had some problems on my machine, that the Qt configure tests could
not detect the endianess.)
diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org 2008-06-10 23:50:44.0 +0200
+++ ./debian/rules 2008-06-11 23:36:26.0 +0200
@@ -65,6 +65,8 @@ ifeq ($(DEB_HOST_ARCH),hppa)
echo "Please update kernel and test again" ; \
exit 5 ; \
fi
+
+ EXTRA_CONFIGURE_OPTS += "-v -big-endian"
endif
# Create mkspecs/glibc-g++ from mkspecs/linux-g++, needed by
GNU/kFreeBSD
And this part replaces the debian patch "70_hppa_ldcw_fix.diff".
Maybe you could name this one "71_hppa_ldcw_fix.diff" and add it to the
to-be-applied patches list?
Benefit of my version is, that the q_ldcw() assembler statement will be
inlined any will perform better than a call to an external funtion.
diff -up ./src/corelib/arch/parisc/arch.pri.org
./src/corelib/arch/parisc/arch.pri
--- ./src/corelib/arch/parisc/arch.pri.org 2008-04-28 15:11:18.0
+0200
+++ ./src/corelib/arch/parisc/arch.pri 2008-06-10 00:19:10.0 +0200
@@ -1,5 +1,7 @@
#
# HP PA-RISC architecture
#
-SOURCES += $$QT_ARCH_CPP/q_ldcw.s \
- $$QT_ARCH_CPP/qatomic_parisc.cpp
+
+hpux*: SOURCES += $$QT_ARCH_CPP/q_ldcw.s
+
+SOURCES += $$QT_ARCH_CPP/qatomic_parisc.cpp
diff -up ./src/corelib/arch/parisc/qatomic_parisc.cpp.org
./src/corelib/arch/parisc/qatomic_parisc.cpp
--- ./src/corelib/arch/parisc/qatomic_parisc.cpp.org 2008-06-10
00:02:32.0 +0200
+++ ./src/corelib/arch/parisc/qatomic_parisc.cpp 2008-06-10
00:09:54.0 +0200
@@ -72,7 +72,21 @@ static int *align16(int *lock)
extern "C" {
+#if defined(Q_OS_LINUX)
+#if defined(__LP64__)
+ #define __LDCW "ldcw,co"
+#else
+ #define __LDCW "ldcw"
+#endif
+#define q_ldcw(addr) ({\
+ unsigned __ret; \
+ __asm__ __volatile__(__LDCW " 0(%1),%0" \
+ : "=r" (__ret) : "r" (addr)); \
+ __ret; \
+ })
+#else /* for HP/UX */
int q_ldcw(volatile int *addr);
+#endif
void q_atomic_lock(int *lock)
{
Full patch attached as well, just in case my mailer breaks the lines.
Could you test it ? Do you need more ?
Best regards,
Helge
diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 2008-06-11 23:34:12.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff 2008-06-11 23:34:23.0 +0200
@@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t
+ UNAME_MACHINE="armv5tel"
+ ;;
+ hppa)
-+ UNAME_MACHINE="parisc64"
++ UNAME_MACHINE="parisc"
+ ;;
+ hurd-i386)
+ UNAME_MACHINE="i686-AT386"
diff -up ./debian/rules.org ./debian/rules
--- ./
Re: kde4libs vs qt4
On Tue, Jun 10, 2008 at 4:19 PM, Helge Deller <[EMAIL PROTECTED]> wrote:
> Yes.
>
> #define UNLOCKED{-1,-1,-1,-1}
Perfect. That will work just fine. The only reason I couldn't use this
for NPTL, was that all the algorithms were written expecting "compare
and swap" semantics, and rewriting core threading code was not my idea
of a fun time.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
Carlos O'Donell wrote:
On Tue, Jun 10, 2008 at 4:10 PM, Helge Deller <[EMAIL PROTECTED]> wrote:
For Qt it might work as I mentioned without copying atomic.h from glibc.
Qt uses ldcw() not directly. Instead it uses q_atomic_lock(), which then
utilizes q_ldcw().
Here is the code (from src/corelib/arch/parisc/qatomic_parisc.cpp):
void q_atomic_lock(int *lock)
{
// ldcw requires a 16-byte aligned address
volatile int *x = align16(lock);
while (q_ldcw(x) == 0)
;
}
So, the 16byte alignment is taken care of by align16().
My attempt was based on having a minimal patch against Qt.
How is align16() implemented? Is the "int *lock" actually a block of
more than 4 ints? If yes, then this will work, and it's similar to the
approach taken by linuxthreads.
Yes.
#define UNLOCKED{-1,-1,-1,-1}
#define UNLOCKED2 UNLOCKED,UNLOCKED
#define UNLOCKED4 UNLOCKED2,UNLOCKED2
#define UNLOCKED8 UNLOCKED4,UNLOCKED4
#define UNLOCKED16UNLOCKED8,UNLOCKED8
#define UNLOCKED32 UNLOCKED16,UNLOCKED16
#define UNLOCKED64 UNLOCKED32,UNLOCKED32
#define UNLOCKED128 UNLOCKED64,UNLOCKED64
#define UNLOCKED256 UNLOCKED128,UNLOCKED128
// use a 4k page for locks
static int locks[256][4] = { UNLOCKED256 };
int *getLock(volatile void *addr)
{ return locks[qHash(const_cast(addr)) % 256]; }
static int *align16(int *lock)
{
ulong off = (((ulong) lock) % 16);
return off ? (int *)(ulong(lock) + 16 - off) : lock;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
On Tue, Jun 10, 2008 at 4:10 PM, Helge Deller <[EMAIL PROTECTED]> wrote:
> For Qt it might work as I mentioned without copying atomic.h from glibc.
> Qt uses ldcw() not directly. Instead it uses q_atomic_lock(), which then
> utilizes q_ldcw().
>
> Here is the code (from src/corelib/arch/parisc/qatomic_parisc.cpp):
>void q_atomic_lock(int *lock)
>{
>// ldcw requires a 16-byte aligned address
>volatile int *x = align16(lock);
>while (q_ldcw(x) == 0)
>;
>}
> So, the 16byte alignment is taken care of by align16().
> My attempt was based on having a minimal patch against Qt.
How is align16() implemented? Is the "int *lock" actually a block of
more than 4 ints? If yes, then this will work, and it's similar to the
approach taken by linuxthreads.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
Carlos O'Donell wrote:
On Mon, Jun 9, 2008 at 6:26 PM, Helge Deller <[EMAIL PROTECTED]> wrote:
attached is a _completely_ untested patch which should
show what's needed. In principle we could
a) copy over the HPUX-parisc architecture files to arch/hppa and apply the
patch on top of the copy (as you suggest above), or
b) alternatively, we could try to merge HPUX's parisc and Linux's HPPA
architecture into the existing Trolltech codebase of parisc.
I'll continue to look into it and will try to clean it up, depending on what
you think which solution (a or b) is best.
Unfortunately I think you're approach won't work due to the alignment
requirements placed on ldcw? It has to be 16-byte aligned according to
the architecture docs.
I was looking into the kde4libs issue, and I think the solution is to
copy atomic.h from glibc and use that interface.
http://sourceware.org/cgi-bin/cvsweb.cgi/ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=glibc
This obviously only works when we have the linux kernel helper routines.
(better yet would be to put atomic.h into gcc, implement the atomic
builtins with that, and then propgate the use of the atomic builtins
to glibc and other software that needs it).
For Qt it might work as I mentioned without copying atomic.h from glibc.
Qt uses ldcw() not directly. Instead it uses q_atomic_lock(), which then
utilizes q_ldcw().
Here is the code (from src/corelib/arch/parisc/qatomic_parisc.cpp):
void q_atomic_lock(int *lock)
{
// ldcw requires a 16-byte aligned address
volatile int *x = align16(lock);
while (q_ldcw(x) == 0)
;
}
So, the 16byte alignment is taken care of by align16().
My attempt was based on having a minimal patch against Qt.
Helge
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
On Tue, Jun 10, 2008 at 09:27:41AM -0400, Carlos O'Donell wrote: > On Mon, Jun 9, 2008 at 6:26 PM, Helge Deller <[EMAIL PROTECTED]> wrote: > > attached is a _completely_ untested patch which should > > show what's needed. In principle we could > > a) copy over the HPUX-parisc architecture files to arch/hppa and apply the > > patch on top of the copy (as you suggest above), or > > b) alternatively, we could try to merge HPUX's parisc and Linux's HPPA > > architecture into the existing Trolltech codebase of parisc. > > > > I'll continue to look into it and will try to clean it up, depending on what > > you think which solution (a or b) is best. > > Unfortunately I think you're approach won't work due to the alignment > requirements placed on ldcw? It has to be 16-byte aligned according to > the architecture docs. > > I was looking into the kde4libs issue, and I think the solution is to > copy atomic.h from glibc and use that interface. > http://sourceware.org/cgi-bin/cvsweb.cgi/ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=glibc > > This obviously only works when we have the linux kernel helper routines. > > (better yet would be to put atomic.h into gcc, implement the atomic > builtins with that, and then propgate the use of the atomic builtins > to glibc and other software that needs it). I revived tausq's vdso work, I think using this to provide the primitives to userland, er, junk, is probably the best idea. GCC should probably use those, and glibc can keep poking the lws itself since you know best? Discuss. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
On Mon, Jun 9, 2008 at 6:26 PM, Helge Deller <[EMAIL PROTECTED]> wrote: > attached is a _completely_ untested patch which should > show what's needed. In principle we could > a) copy over the HPUX-parisc architecture files to arch/hppa and apply the > patch on top of the copy (as you suggest above), or > b) alternatively, we could try to merge HPUX's parisc and Linux's HPPA > architecture into the existing Trolltech codebase of parisc. > > I'll continue to look into it and will try to clean it up, depending on what > you think which solution (a or b) is best. Unfortunately I think you're approach won't work due to the alignment requirements placed on ldcw? It has to be 16-byte aligned according to the architecture docs. I was looking into the kde4libs issue, and I think the solution is to copy atomic.h from glibc and use that interface. http://sourceware.org/cgi-bin/cvsweb.cgi/ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=glibc This obviously only works when we have the linux kernel helper routines. (better yet would be to put atomic.h into gcc, implement the atomic builtins with that, and then propgate the use of the atomic builtins to glibc and other software that needs it). Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
Helge Deller wrote:
Sune Vuorela wrote:
On Friday 06 June 2008, Thibaut VARENE wrote:
On Fri, Jun 6, 2008 at 12:53 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote:
Paer.debian.org is currently locked down, so there is not much I can do
about it myself.
Just for the records, your access to the ESIEE cluster is just a
matter of sending me a non-compromised ssh key ;)
HTH
I now hacked a bit and got stuff working on one of those cluster
machines.
http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4-
x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=file&rev=0&sc=0
This isn't the "real solution" though.
Qt4 has arch specific code for most archs (and a "generic" arch mostly
used for bootstrapping of Qt), but no arch for linux/hppa, so we use
the "generic" arch here.
The real solution involves some hppa assembler (which is way out of my
league). There is a patch in the package by lamont about patching the
hpux code, but I couldn't get taht to work with my quick tests.
To be inspired on what is needed, looking at other archs could be a
inspiration:
qt4-x11-4.4.0$ find . | grep s390
./src/corelib/arch/s390
./src/corelib/arch/s390/arch.pri
./src/corelib/arch/qatomic_s390.h
./include/QtCore/qatomic_s390.h
./include/Qt/qatomic_s390.h
qt4-x11-4.4.0$ find . | grep parisc
./src/corelib/arch/parisc
./src/corelib/arch/parisc/q_ldcw.s
./src/corelib/arch/parisc/qatomic_parisc.cpp
./src/corelib/arch/parisc/arch.pri
./src/corelib/arch/qatomic_parisc.h
./include/QtCore/qatomic_parisc.h
./include/Qt/qatomic_parisc.h
Maybe it would be possible to use gcc's atomic builtin functions ?
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
Haven't looked into it yet, but will do.
Hello Sune,
attached is a _completely_ untested patch which should
show what's needed. In principle we could
a) copy over the HPUX-parisc architecture files to arch/hppa and apply
the patch on top of the copy (as you suggest above), or
b) alternatively, we could try to merge HPUX's parisc and Linux's HPPA
architecture into the existing Trolltech codebase of parisc.
I'll continue to look into it and will try to clean it up, depending on
what you think which solution (a or b) is best.
Helge
diff -up ./src/corelib/arch/parisc/arch.pri.org ./src/corelib/arch/parisc/arch.pri
--- ./src/corelib/arch/parisc/arch.pri.org 2008-04-28 15:11:18.0 +0200
+++ ./src/corelib/arch/parisc/arch.pri 2008-06-10 00:19:10.0 +0200
@@ -1,5 +1,7 @@
#
# HP PA-RISC architecture
#
-SOURCES += $$QT_ARCH_CPP/q_ldcw.s \
- $$QT_ARCH_CPP/qatomic_parisc.cpp
+
+hpux*: SOURCES += $$QT_ARCH_CPP/q_ldcw.s
+
+SOURCES += $$QT_ARCH_CPP/qatomic_parisc.cpp
diff -up ./src/corelib/arch/parisc/qatomic_parisc.cpp.org ./src/corelib/arch/parisc/qatomic_parisc.cpp
--- ./src/corelib/arch/parisc/qatomic_parisc.cpp.org 2008-06-10 00:02:32.0 +0200
+++ ./src/corelib/arch/parisc/qatomic_parisc.cpp 2008-06-10 00:09:54.0 +0200
@@ -72,7 +72,21 @@ static int *align16(int *lock)
extern "C" {
+#if defined(Q_OS_LINUX)
+#if defined(__LP64__)
+ #define __LDCW "ldcw,co"
+#else
+ #define __LDCW "ldcw"
+#endif
+#define q_ldcw(addr) ({ \
+ unsigned __ret; \
+ __asm__ __volatile__(__LDCW " 0(%1),%0" \
+: "=r" (__ret) : "r" (addr)); \
+ __ret; \
+ })
+#else /* for HP/UX */
int q_ldcw(volatile int *addr);
+#endif
void q_atomic_lock(int *lock)
{
Re: kde4libs vs qt4
Sune Vuorela wrote: On Friday 06 June 2008, Thibaut VARENE wrote: On Fri, Jun 6, 2008 at 12:53 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: Paer.debian.org is currently locked down, so there is not much I can do about it myself. Just for the records, your access to the ESIEE cluster is just a matter of sending me a non-compromised ssh key ;) HTH I now hacked a bit and got stuff working on one of those cluster machines. http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4- x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=file&rev=0&sc=0 This isn't the "real solution" though. Qt4 has arch specific code for most archs (and a "generic" arch mostly used for bootstrapping of Qt), but no arch for linux/hppa, so we use the "generic" arch here. The real solution involves some hppa assembler (which is way out of my league). There is a patch in the package by lamont about patching the hpux code, but I couldn't get taht to work with my quick tests. To be inspired on what is needed, looking at other archs could be a inspiration: qt4-x11-4.4.0$ find . | grep s390 ./src/corelib/arch/s390 ./src/corelib/arch/s390/arch.pri ./src/corelib/arch/qatomic_s390.h ./include/QtCore/qatomic_s390.h ./include/Qt/qatomic_s390.h qt4-x11-4.4.0$ find . | grep parisc ./src/corelib/arch/parisc ./src/corelib/arch/parisc/q_ldcw.s ./src/corelib/arch/parisc/qatomic_parisc.cpp ./src/corelib/arch/parisc/arch.pri ./src/corelib/arch/qatomic_parisc.h ./include/QtCore/qatomic_parisc.h ./include/Qt/qatomic_parisc.h Maybe it would be possible to use gcc's atomic builtin functions ? http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html Haven't looked into it yet, but will do. Helge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
On Friday 06 June 2008, Thibaut VARENE wrote: > On Fri, Jun 6, 2008 at 12:53 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: > > Paer.debian.org is currently locked down, so there is not much I can do > > about it myself. > > Just for the records, your access to the ESIEE cluster is just a > matter of sending me a non-compromised ssh key ;) > > HTH I now hacked a bit and got stuff working on one of those cluster machines. http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4- x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=file&rev=0&sc=0 This isn't the "real solution" though. Qt4 has arch specific code for most archs (and a "generic" arch mostly used for bootstrapping of Qt), but no arch for linux/hppa, so we use the "generic" arch here. The real solution involves some hppa assembler (which is way out of my league). There is a patch in the package by lamont about patching the hpux code, but I couldn't get taht to work with my quick tests. To be inspired on what is needed, looking at other archs could be a inspiration: qt4-x11-4.4.0$ find . | grep s390 ./src/corelib/arch/s390 ./src/corelib/arch/s390/arch.pri ./src/corelib/arch/qatomic_s390.h ./include/QtCore/qatomic_s390.h ./include/Qt/qatomic_s390.h qt4-x11-4.4.0$ find . | grep parisc ./src/corelib/arch/parisc ./src/corelib/arch/parisc/q_ldcw.s ./src/corelib/arch/parisc/qatomic_parisc.cpp ./src/corelib/arch/parisc/arch.pri ./src/corelib/arch/qatomic_parisc.h ./include/QtCore/qatomic_parisc.h ./include/Qt/qatomic_parisc.h And please use arch "hppa" as a name, as parisc here means hpux. Qt upstream (trolltech) describes linux/hppa as "community suppported", which means that they aren't really interested, but might accept patches. /Sune -- Genius, I cannot ping a cable, how does it work? First you can never click a kernel in order to overclock the software. signature.asc Description: This is a digitally signed message part.
Re: kde4libs vs qt4
On Fri, Jun 6, 2008 at 12:53 PM, Sune Vuorela <[EMAIL PROTECTED]> wrote: > Paer.debian.org is currently locked down, so there is not much I can do about > it myself. Just for the records, your access to the ESIEE cluster is just a matter of sending me a non-compromised ssh key ;) HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde4libs vs qt4
* Sune Vuorela <[EMAIL PROTECTED]> [080606 12:53]:
> http://buildd.ayous.org/fetch.php?pkg=kde4libs&arch=hppa&ver=4%3A4.0.80-1&stamp=1211907775&file=log&as=raw
>
> I would like to ask again. Could someone with hppa access try to take a look
> at it?
looking at the build log
| /usr/include/qt4/QtCore/qatomic_generic.h:227: error: lvalue required as
unary '&' operand
and at usr/include/qt4/QtCore/qatomic_generic.h:227:
| template
| Q_INLINE_TEMPLATE T *QBasicAtomicPointer::fetchAndStoreOrdered(T *newValue)
| {
| return reinterpret_cast
| (QBasicAtomicPointer_fetchAndStoreOrdered(&reinterpret_cast(&_q_value),
| newValue));
| }
my suggestion would be to buy those QT developers some introductory book about
C++.
They need it. Seriously.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
