ied Dave and Carlos in case they don't read these lists. Dave
and Carlos, this is a problem with the new glibc in Debian unstable.
looks like any app that links libpthread will segfault.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSU
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.
randolph
--
To UNSUBSCRIBE, email to [
> Well, sarge also shipped as 2.6-only, for hppa; so if the answer is that
> this problem happens to go away when upgrading to 2.6, that's probably
> acceptable, since 2.4 kernels will have been unsupported on hppa for a full
> stable release by the time etch comes out.
It doesn't go away with 2.6
ndolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(I trimmed the cc list a bit)
Dave,
Could this actually be a gcc problem?
Take a look at this:
(gdb) bt
#0 0x406dbd20 in __canonicalize_funcptr_for_compare ()
from /usr/lib/debug/libpthread.so.0
#1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8,
oact=0xc0241f50)
at signal
I don't think that's what is happening at all: I think that in one of
these cases, your test file's on-stack fenv_t is aligned, and on the
other it isn't. The code you posted for gcc 4.0 looks fine. I think
the assembly is broken or the definition of fenv_t.
drow is right, as usual. our fenv_t
im to merge this upstream when he returns,
meanwhile perhaps somebody can roll a new glibc package for debian?
randolph
#! /bin/sh -e
# DP: Description: hppa floating point exception handling fix
# DP: Related bugs: Debian #342545
# DP: Dpatch author: Randolph Chung <[EMAIL PROTECTED]>
> The main part of this patch is already in 2.3.2. However,
> Randolph Chung's test code has not been applied. Randolph,
> Could I remove this dpatch?
sure.
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTE
FYI. can we please pick this up from cvs for the next glibc upload?
thx
randolph
- Forwarded message from David Mosberger <[EMAIL PROTECTED]> -
Date: Thu, 27 Mar 2003 17:04:33 -0800
From: David Mosberger <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: IMPORTANT gli
Package: glibc
Version: 2.3.2
Severity: important
Tags: patch
See
http://sources.redhat.com/ml/libc-hacker/2003-09/msg00033.html
for details. Please either apply this, or take it from cvs.
tnx
randolph
#! /bin/sh -e
# All lines beginning with `# DP:' are a description of the patch.
# DP: Desc
thanks
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
#! /bin/sh -e
# DP: Description: Make sure syscall arguments are loaded properly
# DP: Author: Randolph Chung <[EMAIL PROTECTED]>
# DP: Upstream status: Pending
# DP: Date: Sat, 01 Nov 2003 15:36:0
> if (pread(fd, &data, 16, CPUID_TMx86_VENDOR_ID) != 16) {
um that last field is an offset, why does it use the vendor ID as
the offset?
randolph
pgpOkAZGqrkzL.pgp
Description: PGP signature
> I've been using a prgram many years without problem. I have now a
> segmentation fault.
> strace shows this :
> open("/lib/ld-linux.so.2", O_RDONLY)= 3
>
> before the error.
How do you expect us to do anything without knowing what program you are
running?
randolph
113 for file do
i'm no posix expert, but that looks strange to me. changing that to
'for file in $@; do' ... works, and seems to be more "standard"..
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
In reference to a message from Giles Constant, dated Nov 04:
> And zsh too?
>
> [pts/3] >| echo $SHELL
> /usr/bin/zsh
> [pts/3] >| ldd /bin/ls
> ldd: ./: No such file or directory
>
eh? you realize a script runs using the interpreter encoded in the #!
line right?
legolas[10:27] ~% head -1 /usr/
o investigate some more to find out
what's going on.
so, while this is certainly not a *clean* run, it seems to be as good as
what we've had :)
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
the
children are still running.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
; 9 days old.
Looks like these ones are already in cvs. I'll mark them 'pending'.
* #170507: glibc: header goofup on hppa breaks XFree86 compilation
Package: glibc; Severity: serious; Reported by: Branden Robinson <[EMAIL
PROTECTED]>; Tags: help.
Carlos is looking at this one I think.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
in the bug to say, and I'm not sure why this is
> > assigned to glibc.
>
> No, it's not buildd setup; it's the result of a glibc bug (#165456).
that bug is closed... so is this not a problem anymore?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
> I'm working on it. I'm entering examination period in university and my
> time is disappearing. I'm fixing a fesetround() that was just seen on
> HP's test-drive systems (getting more testing is great!).
let me know if i can help :-)
randolph
Package: glibc
Version: 2.3.1-5
Severity: important
Tags: patch
This is a slightly modified patch (from the one I forwarded upstream)
for strncpy.S on ia64. It differs only in that it applies against our
2.3.1 tarball rather than cvs.
Please add to the list.
randolph
--
Randolph Chung
Debian
In reference to a message from Jeff Bailey, dated Dec 05:
> Here's your status update. Please note the "**NEED HELP HERE**"
> sections.
please also pick up 171550
randolph
done in a completely backwards compatible manner.
32-bit kernels are not affected.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
> Oy. I don't have access to a transmeta CPU to do any testing or
> troubleshooting on this. Do you have the skills to look into it more?
> If not, I don't know how quickly this will be gotten to.
This was reported before:
http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00397.htm
> So fixing either glibc or libc6 preinst is needed. From Randolph's mail,
> comparing kernel version with 2.4.19-pa17 in libc6 preinst is needed.
> I've added changes for the current glibc cvs as follows:
looks good to me.
if there's a common place where the kernel version information is
docum
In reference to a message from GOTO Masanori, dated Jan 06:
> At Sun, 5 Jan 2003 23:34:01 -0800,
> Randolph Chung wrote:
> > > So fixing either glibc or libc6 preinst is needed. From Randolph's mail,
> > > comparing kernel version with 2.4.19-pa17 in libc6 preins
> Oops! I'm sorry, I fixed as follows:
> +# Note that parisc64 kernel version scheme is "`uname -r`-64".
[...]
> - if dpkg --compare-versions "$kernel_ver" lt 2.4.19-pa17
> + if dpkg --compare-versions "$kernel_ver" lt 2.4.19-64
> then
> echo WARNING: This v
> The main part of this patch is already in 2.3.2. However,
> Randolph Chung's test code has not been applied. Randolph,
> Could I remove this dpatch?
sure.
randolph
FYI. can we please pick this up from cvs for the next glibc upload?
thx
randolph
- Forwarded message from David Mosberger <[EMAIL PROTECTED]> -
Date: Thu, 27 Mar 2003 17:04:33 -0800
From: David Mosberger <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], debian-ia64@lists.debian.org
Subject: IM
need more help than others because of lack
of upstream support, etc if anyone would like to help do the NPTL
work for hppa, please contact me. There have been various discussions
about this between Carlos and myself, but it's not something that will
happen in a few weeks' time.
randolph
to get
this to work is for us to agree on a workable design for implementing
this. I hope to get that done by the end of the month.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
Package: glibc
Version: 2.3.1-17
Severity: serious
After upgrading to 2.3.1-17, vim will segfault on startup. With the same
version of vim but libc6_2.3.1-16, everything is fine.
randolph
tting upstream shortly.
dpatch attached. please apply.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
#! /bin/sh -e
# All lines beginning with `# DP:' are a description of the patch.
# DP: Description: Define entry.h properly for hppa -- we
Package: glibc
Version: 2.3.1-17
Severity: serious
Filing to make sure we don't release this version of glibc, because it
is very broken on hppa. Needs a gcc-3.2 fix as documented in #193207 and
then a recompile...
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
cations?
yes, anything that uses e.g sigset() will segfault. so far we've seen
this with at least vim, tcpdump and a few other executables.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
be you can use syscall() instead
if you really need to?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
> So it looks like if it's there on i386, it should be there on your
> platform.
>
> Maybe confirm first that it's in that object file and look there?
does it work on any other architecture (other than i386 and powerpc)?
sysdeps/i386/Makefile has a section that pulls in divdi3... if i add a
cor
In reference to a message from Jeff Bailey, dated Sep 02:
> On Mon, Sep 02, 2002 at 07:38:51PM -0400, Carlos O'Donell wrote:
>
> > objdump -t /mnt/flaire/src/glibc-upstream-cvs/libc-build/libc.so.6 | grep divdi3
> > 001173d4 l F .text 0028 __udivdi3
> > *UND
> Are there any alpha, arm, ia64, mips, or superh people on this list?
> If not, I'll specifically ask for people for those when I email
> debian-ports later on.
i'll take ia64.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
> Excellent! Are you willing to send this patch upstream now? (Do you
> want me to do it?) It would be nice to show upstream that this port
> is being hacked on, and it also allows drepper to comment in case it's
> not exactly right.
I'll let Carlos handle feeding this upstream. all those othe
In reference to a message from Randolph Chung, dated Sep 03:
> > Are there any alpha, arm, ia64, mips, or superh people on this list?
> > If not, I'll specifically ask for people for those when I email
> > debian-ports later on.
>
> i'll take ia64.
Inconsist
> To point you in the right direction, this is probably R_IA64_NONE
> showing up in an unexpected place, which is probably a binutils bug.
yeah, we've seen that one before.. that's why we have a ia64-reloc-none
patch in glibc (which i thought was already upstream, but i guess not).
will report ba
drow is right, as usual :-)
randolph
- Forwarded message from Randolph Chung <[EMAIL PROTECTED]> -
From: Randolph Chung <[EMAIL PROTECTED]>
To: "Wichmann, Mats D" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Reply-To: Randolph Chung <[EMAIL PROTECTED]>
i'll try this later
randolph
- Forwarded message from Andreas Schwab <[EMAIL PROTECTED]> -
To: Randolph Chung <[EMAIL PROTECTED]>
Cc: "Wichmann, Mats D" <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: [Linux-ia64] latest glibc snap
In reference to a message from Randolph Chung, dated Sep 03:
> i'll try this later
well, the lazy answer is that this patch works... replaces the existing
ia64-reloc-none patch
i'll try to spend some more time to track down where the reloc is coming
from so we can try t
> I've commited this, with a few changes to the "DP" headers with
> information that I want to see on all the patches in there eventually.
>
> With this, does ia64 now build and run? ia64-perf.dpatch is still
> disabled.
it fails some of the regexp tests... but it builds fine otherwise
./ia64-
> ia64: Randolph Chung
i'm not exactly sure what's the deal here yet, but installing freshly
built 2.2.93 debs in a new chroot on ia64 gives some scary looking
errors:
sh-2.05b# dpkg -i libc6.1_2.2.93-1_ia64.deb libc6.1-dev_2.2.93-1_ia64.deb
locales_2.2.93-1_all.deb
(Reading data
nt, like 8, ld.so works).
I'm guessing this means that our lp (r19) is not setup correctly when
_dl_start is called, but i haven't dug enough into the code to figure
out the details yet.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
or hppa. the
threads get started up, and they go through the for loop ok.. but it
doesn't exit.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> In _dl_start I'm not sure if r19 is expected to be correct or not - I
> suspect that it may not be, and they didn't take into account the idea
> that an integer divide would need to load from a constant pool... why
> on earth is GCC generating an FP divide anyway?
there's no divide insn on pa.
In reference to a message from Jack Howarth, dated Sep 24:
> Carlos,
> So hppa doesn't need any additional libgcc-compat code? Did you
> try running the perl script I posted to see if there are any libgcc
> symbols that are being left undefined in binaries?
>
> http://sources.redhat.com/ml/li
> - math 'tests'
> = Needs to be updated, poking Randolph.
updated and attached. please apply and submit upstream.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
#! /bin/sh -e
# DP: Define hppa libm test accepted ulp
> if (pread(fd, &data, 16, CPUID_TMx86_VENDOR_ID) != 16) {
um that last field is an offset, why does it use the vendor ID as
the offset?
randolph
msg01405/pgp0.pgp
Description: PGP signature
> I've been using a prgram many years without problem. I have now a
> segmentation fault.
> strace shows this :
> open("/lib/ld-linux.so.2", O_RDONLY)= 3
>
> before the error.
How do you expect us to do anything without knowing what program you are
running?
randolph
--
To UNSUBSCRIBE, ema
113 for file do
i'm no posix expert, but that looks strange to me. changing that to
'for file in $@; do' ... works, and seems to be more "standard"..
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, e
In reference to a message from Giles Constant, dated Nov 04:
> And zsh too?
>
> [pts/3] >| echo $SHELL
> /usr/bin/zsh
> [pts/3] >| ldd /bin/ls
> ldd: ./: No such file or directory
>
eh? you realize a script runs using the interpreter encoded in the #!
line right?
legolas[10:27] ~% head -1 /usr/
o investigate some more to find out
what's going on.
so, while this is certainly not a *clean* run, it seems to be as good as
what we've had :)
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the
children are still running.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
.
Looks like these ones are already in cvs. I'll mark them 'pending'.
* #170507: glibc: header goofup on hppa breaks XFree86 compilation
Package: glibc; Severity: serious; Reported by: Branden Robinson <[EMAIL PROTECTED]>;
Tags: help.
Carlos is looking at this one I think
the bug to say, and I'm not sure why this is
> > assigned to glibc.
>
> No, it's not buildd setup; it's the result of a glibc bug (#165456).
that bug is closed... so is this not a problem anymore?
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http
> I'm working on it. I'm entering examination period in university and my
> time is disappearing. I'm fixing a fesetround() that was just seen on
> HP's test-drive systems (getting more testing is great!).
let me know if i can help :-)
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Package: glibc
Version: 2.3.1-5
Severity: important
Tags: patch
This is a slightly modified patch (from the one I forwarded upstream)
for strncpy.S on ia64. It differs only in that it applies against our
2.3.1 tarball rather than cvs.
Please add to the list.
randolph
--
Randolph Chung
Debian
In reference to a message from Jeff Bailey, dated Dec 05:
> Here's your status update. Please note the "**NEED HELP HERE**"
> sections.
please also pick up 171550
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
done in a completely backwards compatible manner.
32-bit kernels are not affected.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Oy. I don't have access to a transmeta CPU to do any testing or
> troubleshooting on this. Do you have the skills to look into it more?
> If not, I don't know how quickly this will be gotten to.
This was reported before:
http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00397.htm
> So fixing either glibc or libc6 preinst is needed. From Randolph's mail,
> comparing kernel version with 2.4.19-pa17 in libc6 preinst is needed.
> I've added changes for the current glibc cvs as follows:
looks good to me.
if there's a common place where the kernel version information is
docum
In reference to a message from GOTO Masanori, dated Jan 06:
> At Sun, 5 Jan 2003 23:34:01 -0800,
> Randolph Chung wrote:
> > > So fixing either glibc or libc6 preinst is needed. From Randolph's mail,
> > > comparing kernel version with 2.4.19-pa17 in libc6 preins
> Oops! I'm sorry, I fixed as follows:
> +# Note that parisc64 kernel version scheme is "`uname -r`-64".
[...]
> - if dpkg --compare-versions "$kernel_ver" lt 2.4.19-pa17
> + if dpkg --compare-versions "$kernel_ver" lt 2.4.19-64
> then
> echo WARNING: This v
In reference to a message from Johan Walles, dated Jan 27:
> H. S. Teoh wrote:
> >Could this be an architecture-specific problem? I'm on an i386 FYI.
>
> Yes, this is IA64 specific.
see
http://lists.debian.org/debian-glibc/2003/debian-glibc-200301/msg00328.html
randolph
--
To UNSUBSCRIBE, ema
I haven't done it.
yup, this should work. Alternatively just build a new 2.4.19/20 kernel
yourself, boot with that, and then do the glibc upgrade.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
d symbol: __clz_tab
What am i missing?
thanks
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> +libc {
> + GLIBC_2.2 {
> +# libgcc-compat.
> +__clz_tab;
> + }
> +}
>
> Does this help?
nope :(
randolph
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ch doesn't work,
but if you want to give it a try, pls go ahead :)
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> The attached patch seems to give the correct symbol visibility for me.
yup, i was working on a similar one this morning. anyway, the attached
one is tested against latest glibc-package bits.
thanks all,
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
h
n't seen any of these reported on real systems, so how about
if we go with just the clz_tab patch first, and i'll add these later
if people report problems? (or if Guido's script can tell which
binaries need these symbols, i'll check them explicitly)
thanks
randolph
--
Randol
> http://honk.physik.uni-konstanz.de/linux-mips/glibc/compat-symbols/found-hppa-all
most of these look like false positives. i have about half of
those executables installed on my system and they all work fine.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
h
In reference to a message from Guido Guenther, dated Mar 01:
> On Sat, Mar 01, 2003 at 12:04:54PM -0800, Randolph Chung wrote:
> > most of these look like false positives. i have about half of
> > those executables installed on my system and they all work fine.
> Just to be
In reference to a message from Guido Guenther, dated Mar 01:
> On Sat, Mar 01, 2003 at 12:38:50PM -0800, Randolph Chung wrote:
> > (i also notice that your list doesn't include __clz_tab?)
> Yes, I already wondered why. Could you send me a
> readelf -a libgcc_s.so | gr
# DP: Description: Add unwind information for the plt fixup routine
# DP: Author: Randolph Chung ([EMAIL PROTECTED])
# DP: Upstream status: Submitted and accepted on 2004-11-20
# DP: Status Details: Tested with no regressions.
# DP: Date: 2004-11-19
if [ $# -ne 2 ]; then
echo >&2 "`bas
tag 284449 +patch
thanks
This patch fixes the utimes() problem on hppa -- the cvs patch applied
to debian's glibc has a bug in it. tested against 2.3.2.ds1-19
thanks,
randolph
#! /bin/sh -e
# DP: Description: Don't define __ASSUME_UTIMES for hppa
# DP: Author: Randolph Chung <[EM
> And while you're at it - what about submitting a kernel patch to add
> sys_utimes on parisc?
willy and i talked about this yesterday. i'll commit this directly to
the parisc tree.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tau
81 matches
Mail list logo
