[parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

Dear list-members,

A new year is here and it's time to look back and say, hey, we did a
great job, hacked on many things and made parisc a better port!

============
GNU/binutils
============

Maybe someone can comment on this? Randolph was great enough to remove
silly ltp relocations from static binaries. Without the loader running
the ltp is never read from the DT_PLTGOT dynamic entries... so it just
made sense to translate these into dp relative relocations. dlopen from
static binaries still doesn't work, minor problem really.

I know that hppa is not really multi-arch? We have to have two separate
binaries to do 32 and 64-bit work. Someone want a project? :)

======
GNU/cc
======

jda, you're the best person to talk about how gcc is doing. I can build
kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual
workflow when it comes to testing.

jda, you mentioned that the libstdc++ testsuite could be examined in
order to fix some of our failures.

============
GNU/debugger
============

Our gdb has no visibility upstream. I'm taking a hiatus from glibc to
fix gdb. I volunteered for this like 2 years ago, but glibc took a long
time to fix.

===============
ELF64 Userspace
===============

32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo.
A good project might be for someone to implement the set/get/make/swap
context calls in userspace, takers are welcome! I will *not* be working
ELF64 yet, without a working gdb it's quite hard to do *anything*. I
just recently learned how to poke insns into binary files for
debugging... it's not as much fun as you think ;)

I need to do similar signal hacking for ia64 or upstream may never
accept my linux/kernel/* patches. Worst-case has us absorb the changes
into our arch directory and nobody else benefits from the framework :(

============================
Kernel<->Usrspace Atomic ops
============================

Will work on these whilst I hack gdb. Expect a first cut in a month or
so.

========
GNU/libc
========

I'm here to speak on behalf of the userspace work we have done. Glibc is
in *much* better shape than before, a year ago there were so many errors
I didn't know where to begin. Our current list of failures is down to:

make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136
make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1
make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136
make[1]: *** [math/tests] Error 2

These three tests are related to the fact that we don't have long double
supported properly. Waiting on HP to release the code. An alternative is
a long double with only 64-bits, though this would be the *last* thing
on the list of userspace problems to fix (it would cement our long
double ABI at 64-bits).

make[2]: *** [/glibc-work/build-hppa/stdlib/tst-strtod.out] Error 1
make[2]: *** [/glibc-work/build-hppa/stdlib/bug-strtod.out] Error 1
make[1]: *** [stdlib/tests] Error 2

Same issue, no long double support, so string to double fails.

make[2]: *** [/glibc-work/build-hppa/dlfcn/tststatic.out] Error 139
make[1]: *** [dlfcn/tests] Error 2

The value of an address is interpreted as a function descriptor and
erroneously loads the wrong stuff during the jump. This will require a
bit more work to track down the particular PLABEL32 or IPLT relocation
causing the problem.

The trickiest bugs to remove were all those symbol visibility bugs,
which weren't related to symbol visibility at all. Infact due to our
erroneous function pointer implementation we were skipping all ld.so.1
COPY relocations. I ported hppa over to use the generic function
descriptor code and was finally able to process all of ld's COPY relocs.
I have no idea if this was ever a problem for symbols other than
_r_debug. Gdb may benefit from this.

Profiling is fixed thanks to Randolph! And I just completed the required
changes to get sprof working for shared libraries. I can finally enable
*other* people to track down elusive performance problems in shared
library code.

Aside from that we are no longer in danger of losing glibc, a few more
patches and upstream will be synchronized! I think Ulrich might be
growing to accept me as the hppa maintainer :)

Cheers,
Carlos.

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[John David Anglin]

> ======
> GNU/cc
> ======
> 
> jda, you're the best person to talk about how gcc is doing. I can build
> kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual
> workflow when it comes to testing.

The PA backend is in fairly reasonable shape.  Most of the remaining
PA bugs are limitations in the current implementation.  We are still
restricted in distance for floating point and branch on bit.  Frame
sizes on hppa64 are limited to < 2**36 bytes.  There is a bug which
causes arguments in const functions to get optimized away.  There is
a bug which affects constant elimination.  On the 64-bit port, constants
don't appear to be substituted/combined properly with if_then_else
insns.  As a result, some if statements don't get simplified.

2004 Projects:

1) Squash remaining bugs and limitations.
2) Finish libffi port.
3) Add PA specific stuff for java.
4) Develop TLS specification and GCC support.
5) Allow small range of floating point registers to be used
   for integer multiplication in kernel.  This should help
   64-bit kernel.
6) Thread support for ada.

As usual, I expect there will be many ups and downs in the process.
So, we won't get as far as we would like.

> jda, you mentioned that the libstdc++ testsuite could be examined in
> order to fix some of our failures.

Yes, these need to be looked at before 3.4 is released.  Some appear
to be related to long double support.  Just guessing, but I think the
rest are locale or glibc related.

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

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[John David Anglin]

> ======
> GNU/cc
> ======
> 
> jda, you're the best person to talk about how gcc is doing. I can build
> kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual
> workflow when it comes to testing.

The PA backend is in fairly reasonable shape.  Most of the remaining
PA bugs are limitations in the current implementation.  We are still
restricted in distance for floating point and branch on bit.  Frame
sizes on hppa64 are limited to < 2**36 bytes.  There is a bug which
causes arguments in const functions to get optimized away.  There is
a bug which affects constant elimination.  On the 64-bit port, constants
don't appear to be substituted/combined properly with if_then_else
insns.  As a result, some if statements don't get simplified.

2004 Projects:

1) Squash remaining bugs and limitations.
2) Finish libffi port.
3) Add PA specific stuff for java.
4) Develop TLS specification and GCC support.
5) Allow small range of floating point registers to be used
   for integer multiplication in kernel.  This should help
   64-bit kernel.
6) Thread support for ada.

As usual, I expect there will be many ups and downs in the process.
So, we won't get as far as we would like.

> jda, you mentioned that the libstdc++ testsuite could be examined in
> order to fix some of our failures.

Yes, these need to be looked at before 3.4 is released.  Some appear
to be related to long double support.  Just guessing, but I think the
rest are locale or glibc related.

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

[parisc-linux] Re: [Status] hppa's userspace in 2004 (looking back)

[Matthew Wilcox]

On Mon, Jan 05, 2004 at 12:21:46PM -0500, Carlos O'Donell wrote:
> A new year is here and it's time to look back and say, hey, we did a
> great job, hacked on many things and made parisc a better port!

Carlos, thank you for all the work you've put in over the last year
and more.  We would be significantly worse off without your efforts.
I'm sure many people who read this aren't aware just how much work you've
put in to make PA/Linux as good as it is -- and that's a compliment.

> ============
> GNU/binutils
> ============
> 
> Maybe someone can comment on this? Randolph was great enough to remove
> silly ltp relocations from static binaries. Without the loader running
> the ltp is never read from the DT_PLTGOT dynamic entries... so it just
> made sense to translate these into dp relative relocations. dlopen from
> static binaries still doesn't work, minor problem really.
> 
> I know that hppa is not really multi-arch? We have to have two separate
> binaries to do 32 and 64-bit work. Someone want a project? :)

I have an unfinished project to get all the remnants of (%sr0,xx) right
from 2-bit sr fields.  I think I can do quite a simplification here,
but I haven't got round to finishing it off.  I'll take another look
in February.

> ============
> GNU/debugger
> ============
> 
> Our gdb has no visibility upstream. I'm taking a hiatus from glibc to
> fix gdb. I volunteered for this like 2 years ago, but glibc took a long
> time to fix.

The bounty is currently set at one bottle of single malt (in the
10-20 year old range, not the 50 year old range ;-)

> ===============
> ELF64 Userspace
> ===============
> 
> 32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo.
> A good project might be for someone to implement the set/get/make/swap
> context calls in userspace, takers are welcome! I will *not* be working
> ELF64 yet, without a working gdb it's quite hard to do *anything*. I
> just recently learned how to poke insns into binary files for
> debugging... it's not as much fun as you think ;)
> 
> I need to do similar signal hacking for ia64 or upstream may never
> accept my linux/kernel/* patches. Worst-case has us absorb the changes
> into our arch directory and nobody else benefits from the framework :(

There's certainly enthusiasm for these changes -- the more
32-bit-emulation code we can share, the better.  If you don't have time
for this, I can take this on.  But as I said, not till February.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

[parisc-linux] Re: [Status] hppa's userspace in 2004 (looking back)

[Matthew Wilcox]

On Mon, Jan 05, 2004 at 12:21:46PM -0500, Carlos O'Donell wrote:
> A new year is here and it's time to look back and say, hey, we did a
> great job, hacked on many things and made parisc a better port!

Carlos, thank you for all the work you've put in over the last year
and more.  We would be significantly worse off without your efforts.
I'm sure many people who read this aren't aware just how much work you've
put in to make PA/Linux as good as it is -- and that's a compliment.

> ============
> GNU/binutils
> ============
> 
> Maybe someone can comment on this? Randolph was great enough to remove
> silly ltp relocations from static binaries. Without the loader running
> the ltp is never read from the DT_PLTGOT dynamic entries... so it just
> made sense to translate these into dp relative relocations. dlopen from
> static binaries still doesn't work, minor problem really.
> 
> I know that hppa is not really multi-arch? We have to have two separate
> binaries to do 32 and 64-bit work. Someone want a project? :)

I have an unfinished project to get all the remnants of (%sr0,xx) right
from 2-bit sr fields.  I think I can do quite a simplification here,
but I haven't got round to finishing it off.  I'll take another look
in February.

> ============
> GNU/debugger
> ============
> 
> Our gdb has no visibility upstream. I'm taking a hiatus from glibc to
> fix gdb. I volunteered for this like 2 years ago, but glibc took a long
> time to fix.

The bounty is currently set at one bottle of single malt (in the
10-20 year old range, not the 50 year old range ;-)

> ===============
> ELF64 Userspace
> ===============
> 
> 32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo.
> A good project might be for someone to implement the set/get/make/swap
> context calls in userspace, takers are welcome! I will *not* be working
> ELF64 yet, without a working gdb it's quite hard to do *anything*. I
> just recently learned how to poke insns into binary files for
> debugging... it's not as much fun as you think ;)
> 
> I need to do similar signal hacking for ia64 or upstream may never
> accept my linux/kernel/* patches. Worst-case has us absorb the changes
> into our arch directory and nobody else benefits from the framework :(

There's certainly enthusiasm for these changes -- the more
32-bit-emulation code we can share, the better.  If you don't have time
for this, I can take this on.  But as I said, not till February.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [parisc-linux] Re: [Status] hppa's userspace in 2004 (looking back)

[Helge Deller]

On Monday 05 January 2004 20:33, Matthew Wilcox wrote:
> On Mon, Jan 05, 2004 at 12:21:46PM -0500, Carlos O'Donell wrote:
> > A new year is here and it's time to look back and say, hey, we did a
> > great job, hacked on many things and made parisc a better port!
> 
> Carlos, thank you for all the work you've put in over the last year
> and more.  We would be significantly worse off without your efforts.
> I'm sure many people who read this aren't aware just how much work you've
> put in to make PA/Linux as good as it is -- and that's a compliment.

Full ACK !
Thanks Carlos  and  JDA !

Helge

Re: [parisc-linux] Re: [Status] hppa's userspace in 2004 (looking back)

[Helge Deller]

On Monday 05 January 2004 20:33, Matthew Wilcox wrote:
> On Mon, Jan 05, 2004 at 12:21:46PM -0500, Carlos O'Donell wrote:
> > A new year is here and it's time to look back and say, hey, we did a
> > great job, hacked on many things and made parisc a better port!
> 
> Carlos, thank you for all the work you've put in over the last year
> and more.  We would be significantly worse off without your efforts.
> I'm sure many people who read this aren't aware just how much work you've
> put in to make PA/Linux as good as it is -- and that's a compliment.

Full ACK !
Thanks Carlos  and  JDA !

Helge

Re: [parisc-linux] Re: [Status] hppa's userspace in 2004 (looking back)

[Christopher Strong]

> > Carlos, thank you for all the work you've put in over the last year
> > and more.  We would be significantly worse off without your efforts.
> > I'm sure many people who read this aren't aware just how much work you've
> > put in to make PA/Linux as good as it is -- and that's a compliment.

Same here; there are still a lot of issues with my C3000, but that does
not mean it's not great; the machine runs and is stable, even with the
USB and frame buffer issues.  Totally stable.  I am VERY PLEASED with
the progress that has been made on HPPA linux; this machine is now one
I depend on, because I know I can.

Thanks for all the work.

-Chris

Re: [parisc-linux] Re: [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

On Mon, Jan 05, 2004 at 05:00:48PM -0700, Christopher Strong wrote:
> Same here; there are still a lot of issues with my C3000, but that does
> not mean it's not great; the machine runs and is stable, even with the
> USB and frame buffer issues.  Totally stable.  I am VERY PLEASED with
> the progress that has been made on HPPA linux; this machine is now one
> I depend on, because I know I can.
> 
> Thanks for all the work.

Thanks guys! The learning process is worth it's weight in gold :)
I'm always glad to hear people rely on their parisc-linux machines to
get work done. Hey, my c3k runs all the home accounts in the lab!

c.

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

On Mon, Jan 05, 2004 at 01:48:54PM -0500, John David Anglin wrote:
> As usual, I expect there will be many ups and downs in the process.
> So, we won't get as far as we would like.
> 
> > jda, you mentioned that the libstdc++ testsuite could be examined in
> > order to fix some of our failures.
> 
> Yes, these need to be looked at before 3.4 is released.  Some appear
> to be related to long double support.  Just guessing, but I think the
> rest are locale or glibc related.

Does this seem like a reasonable triage list?

a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.

c.

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

On Mon, Jan 05, 2004 at 01:48:54PM -0500, John David Anglin wrote:
> As usual, I expect there will be many ups and downs in the process.
> So, we won't get as far as we would like.
> 
> > jda, you mentioned that the libstdc++ testsuite could be examined in
> > order to fix some of our failures.
> 
> Yes, these need to be looked at before 3.4 is released.  Some appear
> to be related to long double support.  Just guessing, but I think the
> rest are locale or glibc related.

Does this seem like a reasonable triage list?

a. gdb.
b. atomic kernel ops.
c. libstdc++ failures.

c.

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[John David Anglin]

> Does this seem like a reasonable triage list?
> 
> a. gdb.
> b. atomic kernel ops.
> c. libstdc++ failures.

I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite
timeline yet.  Would you like to try to get atomic kernel ops in 2.6.x?
How important is the kernel timeline for this work?  We missed gdb 6.0.
A couple of quick hacks allow 6.0 to build for hppa-linux.  Bug fixes are
another matter.

Probably, the v3 issues involve doing enough research to file a PR if
the problem is generic, fix the problem if it is GCC hppa specific.
If a problem turns out to be glibc/kernel related, we can wait for
a fix ;)

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

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[John David Anglin]

> Does this seem like a reasonable triage list?
> 
> a. gdb.
> b. atomic kernel ops.
> c. libstdc++ failures.

I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite
timeline yet.  Would you like to try to get atomic kernel ops in 2.6.x?
How important is the kernel timeline for this work?  We missed gdb 6.0.
A couple of quick hacks allow 6.0 to build for hppa-linux.  Bug fixes are
another matter.

Probably, the v3 issues involve doing enough research to file a PR if
the problem is generic, fix the problem if it is GCC hppa specific.
If a problem turns out to be glibc/kernel related, we can wait for
a fix ;)

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

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

On Tue, Jan 06, 2004 at 01:16:44AM -0500, John David Anglin wrote:
> > Does this seem like a reasonable triage list?
> > 
> > a. gdb.
> > b. atomic kernel ops.
> > c. libstdc++ failures.
> 
> I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite
> timeline yet.  Would you like to try to get atomic kernel ops in 2.6.x?
> How important is the kernel timeline for this work?  We missed gdb 6.0.
> A couple of quick hacks allow 6.0 to build for hppa-linux.  Bug fixes are
> another matter.

No timeline, just icing.
 
> Probably, the v3 issues involve doing enough research to file a PR if
> the problem is generic, fix the problem if it is GCC hppa specific.
> If a problem turns out to be glibc/kernel related, we can wait for
> a fix ;)

I can interleave b,c in order to help you out? :)

80% gdb.
10% atomic ops.
10% libstc++ failures.

c.

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

On Tue, Jan 06, 2004 at 01:16:44AM -0500, John David Anglin wrote:
> > Does this seem like a reasonable triage list?
> > 
> > a. gdb.
> > b. atomic kernel ops.
> > c. libstdc++ failures.
> 
> I expect GCC 3.4 is coming in 2-3 months, although there isn't a definite
> timeline yet.  Would you like to try to get atomic kernel ops in 2.6.x?
> How important is the kernel timeline for this work?  We missed gdb 6.0.
> A couple of quick hacks allow 6.0 to build for hppa-linux.  Bug fixes are
> another matter.

No timeline, just icing.
 
> Probably, the v3 issues involve doing enough research to file a PR if
> the problem is generic, fix the problem if it is GCC hppa specific.
> If a problem turns out to be glibc/kernel related, we can wait for
> a fix ;)

I can interleave b,c in order to help you out? :)

80% gdb.
10% atomic ops.
10% libstc++ failures.

c.

RE: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Joel Soete]

Hi Carlos,


>========
>GNU/libc
>========
>
>I'm here to speak on behalf of the userspace work we have done. Glibc is
>in *much* better shape than before, a year ago there were so many errors
>I didn't know where to begin. Our current list of failures is down to:
>
>make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136
>make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1
>make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136
>make[1]: *** [math/tests] Error 2
>
>These three tests are related to the fact that we don't have long double
>supported properly. Waiting on HP to release the code.

Looking for something similar, some time ago, I figure out that Paul released
some interesting hp lib stuff in gcc snapshot (the futur 3.4) into gcc/config/pa
 as milli64.S (optimized div, mul, ....), ... (my last cvs update was dated
of dec 2003 and it seems that this feature was dated of Aug 2003 so I trust
that last debian package gcc-snapshot should also contain this material)

I just don't yet reach to rebuild it (gcc-snapshot) following toolchain process
(but I don't much retry because of gnu pserver cvs pb; in the mean time I
read that new anonymous access would be with ssh, even though last weekend
it was not yet operational?) because I much work on 3.3.3.

hth,
    Joel

-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

RE: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Joel Soete]

Hi Carlos,


>========
>GNU/libc
>========
>
>I'm here to speak on behalf of the userspace work we have done. Glibc is
>in *much* better shape than before, a year ago there were so many errors
>I didn't know where to begin. Our current list of failures is down to:
>
>make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136
>make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1
>make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136
>make[1]: *** [math/tests] Error 2
>
>These three tests are related to the fact that we don't have long double
>supported properly. Waiting on HP to release the code.

Looking for something similar, some time ago, I figure out that Paul released
some interesting hp lib stuff in gcc snapshot (the futur 3.4) into gcc/config/pa
 as milli64.S (optimized div, mul, ....), ... (my last cvs update was dated
of dec 2003 and it seems that this feature was dated of Aug 2003 so I trust
that last debian package gcc-snapshot should also contain this material)

I just don't yet reach to rebuild it (gcc-snapshot) following toolchain process
(but I don't much retry because of gnu pserver cvs pb; in the mean time I
read that new anonymous access would be with ssh, even though last weekend
it was not yet operational?) because I much work on 3.3.3.

hth,
    Joel

-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Joel Soete]

Joel Soete wrote:
[snip]
> (but I don't much retry because of gnu pserver cvs pb; in the mean time I
> read that new anonymous access would be with ssh, even though last weekend
> it was not yet operational?) 
[snip]

CVSROOT=":ext:anoncvs@subversions.gnu.org:/cvsroot/gcc"

seems to be operational now with CVS_RSH="ssh"

hth,
	Joel

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Joel Soete]

Joel Soete wrote:
[snip]
> (but I don't much retry because of gnu pserver cvs pb; in the mean time I
> read that new anonymous access would be with ssh, even though last weekend
> it was not yet operational?) 
[snip]

CVSROOT=":ext:anoncvs@subversions.gnu.org:/cvsroot/gcc"

seems to be operational now with CVS_RSH="ssh"

hth,
	Joel

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Joel Soete]

Hi Carlos,

Here is finaly the pb I encounter when I try to rebuild the toolchain with
gcc-snapshot at the time of glibc build:
[snip]
/Develop/parisc-linux/xc/bin/hppa-linux-gcc -nostdlib -nostartfiles -o /Develop/parisc-linux/build/glibc/iconv/iconvconfig
 -Wl,-dynamic-linker=/opt/palinux/hppa-linux/lib/ld.so.1    /Develop/parisc-linux/build/glibc/csu/crt1.o
/Develop/parisc-linux/build/glibc/csu/crti.o `/Develop/parisc-linux/xc/bin/hppa-linux-gcc
--print-file-name=crtbegin.o` /Develop/parisc-linux/build/glibc/iconv/iconvconfig.o
/Develop/parisc-linux/build/glibc/iconv/strtab.o /Develop/parisc-linux/build/glibc/iconv/xmalloc.o
/Develop/parisc-linux/build/glibc/iconv/hash-string.o  -Wl,-rpath-link=/Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/gl
ibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/parisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads
/Develop/parisc-linux/build/glibc/libc.so.6 /Develop/parisc-linux/build/glibc/libc_nonshared.a
-lgcc `/Develop/parisc-linux/xc/bin/hppa-linux-gcc --print-file-name=crtend.o`
/Develop/parisc-linux/build/glibc/csu/crtn.o
/Develop/parisc-linux/build/glibc/elf/ld.so.1: undefined reference to `set_dp'
collect2: ld returned 1 exit status
make[2]: *** [/Develop/parisc-linux/build/glibc/iconv/iconvconfig] Error
1
make[2]: Leaving directory `/Develop/parisc-linux/sources/glibc/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/Develop/parisc-linux/sources/glibc'
make: *** [all] Error 2

the glibc src cames from last debian pkg with patches applied and configured
with following options:
# unset LD_LIBRARY_PATH; unset LD_RUN_PATH; export CC=/Develop/parisc-linux/xc/bin/hppa-linux-gcc;
export CLFAGS="-O2 -g";  export PATH="/Develop/parisc-linux/xc/bin:$PATH";
/Develop/parisc-linux/sources/glibc/configure --target=hppa-linux --host=hppa-linux
--build=hppa-linux --prefix=/opt/palinux/hppa-linux --without-cvs --disable-profile
--enable-hacker-mode --enable-add-ons=linuxthreads --with-headers=/Develop/parisc-linux/sources/linux/include


and the gcc-snapshot sources cames from the latest gcc-scnapshot-20040110
debian pkg and the 'preliminary x compiler' is configured with following
options:
# export PATH="/Develop/parisc-linux/xc/bin:$PATH"; /Develop/parisc-linux/sources/gcc/configure
--target=hppa-linux --host=hppa-linux --build=hppa-linux --prefix=/Develop/parisc-linux/xc
--disable-shared --disable-nls --enable-languages=c 

Any idea?

Thanks in advance,
    Joel

>-- Original Message --
>Date: Fri, 09 Jan 2004 20:37:07 +0000
>From: Joel Soete <soete.joel@tiscali.be>
>To: Carlos O'Donell <carlos@baldric.uwo.ca>
>Cc: parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Subject: Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)
>
>
>Joel Soete wrote:
[snip]
> (but I don't much retry because of gnu pserver cvs pb; in the mean time
I
> read that new anonymous access would be with ssh, even though last weekend
> it was not yet operational?) 
[snip]

CVSROOT=":ext:anoncvs@subve
>sions.gnu.org:/cvsroot/gcc"

seems to be operational now with CVS_RSH="ssh"

hth,
	Joel

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listi
>fo/parisc-linux



-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Joel Soete]

Hi Carlos,

Here is finaly the pb I encounter when I try to rebuild the toolchain with
gcc-snapshot at the time of glibc build:
[snip]
/Develop/parisc-linux/xc/bin/hppa-linux-gcc -nostdlib -nostartfiles -o /Develop/parisc-linux/build/glibc/iconv/iconvconfig
 -Wl,-dynamic-linker=/opt/palinux/hppa-linux/lib/ld.so.1    /Develop/parisc-linux/build/glibc/csu/crt1.o
/Develop/parisc-linux/build/glibc/csu/crti.o `/Develop/parisc-linux/xc/bin/hppa-linux-gcc
--print-file-name=crtbegin.o` /Develop/parisc-linux/build/glibc/iconv/iconvconfig.o
/Develop/parisc-linux/build/glibc/iconv/strtab.o /Develop/parisc-linux/build/glibc/iconv/xmalloc.o
/Develop/parisc-linux/build/glibc/iconv/hash-string.o  -Wl,-rpath-link=/Develop/parisc-linux/build/glibc:/Develop/parisc-linux/build/glibc/math:/Develop/parisc-linux/build/glibc/elf:/Develop/parisc-linux/build/glibc/dlfcn:/Develop/parisc-linux/build/gl
ibc/nss:/Develop/parisc-linux/build/glibc/nis:/Develop/parisc-linux/build/glibc/rt:/Develop/parisc-linux/build/glibc/resolv:/Develop/parisc-linux/build/glibc/crypt:/Develop/parisc-linux/build/glibc/linuxthreads
/Develop/parisc-linux/build/glibc/libc.so.6 /Develop/parisc-linux/build/glibc/libc_nonshared.a
-lgcc `/Develop/parisc-linux/xc/bin/hppa-linux-gcc --print-file-name=crtend.o`
/Develop/parisc-linux/build/glibc/csu/crtn.o
/Develop/parisc-linux/build/glibc/elf/ld.so.1: undefined reference to `set_dp'
collect2: ld returned 1 exit status
make[2]: *** [/Develop/parisc-linux/build/glibc/iconv/iconvconfig] Error
1
make[2]: Leaving directory `/Develop/parisc-linux/sources/glibc/iconv'
make[1]: *** [iconv/others] Error 2
make[1]: Leaving directory `/Develop/parisc-linux/sources/glibc'
make: *** [all] Error 2

the glibc src cames from last debian pkg with patches applied and configured
with following options:
# unset LD_LIBRARY_PATH; unset LD_RUN_PATH; export CC=/Develop/parisc-linux/xc/bin/hppa-linux-gcc;
export CLFAGS="-O2 -g";  export PATH="/Develop/parisc-linux/xc/bin:$PATH";
/Develop/parisc-linux/sources/glibc/configure --target=hppa-linux --host=hppa-linux
--build=hppa-linux --prefix=/opt/palinux/hppa-linux --without-cvs --disable-profile
--enable-hacker-mode --enable-add-ons=linuxthreads --with-headers=/Develop/parisc-linux/sources/linux/include


and the gcc-snapshot sources cames from the latest gcc-scnapshot-20040110
debian pkg and the 'preliminary x compiler' is configured with following
options:
# export PATH="/Develop/parisc-linux/xc/bin:$PATH"; /Develop/parisc-linux/sources/gcc/configure
--target=hppa-linux --host=hppa-linux --build=hppa-linux --prefix=/Develop/parisc-linux/xc
--disable-shared --disable-nls --enable-languages=c 

Any idea?

Thanks in advance,
    Joel

>-- Original Message --
>Date: Fri, 09 Jan 2004 20:37:07 +0000
>From: Joel Soete <soete.joel@tiscali.be>
>To: Carlos O'Donell <carlos@baldric.uwo.ca>
>Cc: parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Subject: Re: [parisc-linux] [Status] hppa's userspace in 2004 (looking back)
>
>
>Joel Soete wrote:
[snip]
> (but I don't much retry because of gnu pserver cvs pb; in the mean time
I
> read that new anonymous access would be with ssh, even though last weekend
> it was not yet operational?) 
[snip]

CVSROOT=":ext:anoncvs@subve
>sions.gnu.org:/cvsroot/gcc"

seems to be operational now with CVS_RSH="ssh"

hth,
	Joel

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listi
>fo/parisc-linux



-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr

[parisc-linux] [Status] hppa's userspace in 2004 (looking back)

[Carlos O'Donell]

Dear list-members,

A new year is here and it's time to look back and say, hey, we did a
great job, hacked on many things and made parisc a better port!

============
GNU/binutils
============

Maybe someone can comment on this? Randolph was great enough to remove
silly ltp relocations from static binaries. Without the loader running
the ltp is never read from the DT_PLTGOT dynamic entries... so it just
made sense to translate these into dp relative relocations. dlopen from
static binaries still doesn't work, minor problem really.

I know that hppa is not really multi-arch? We have to have two separate
binaries to do 32 and 64-bit work. Someone want a project? :)

======
GNU/cc
======

jda, you're the best person to talk about how gcc is doing. I can build
kernels with 3.3.3, sadly with the anon cvs down it's messed up my usual
workflow when it comes to testing.

jda, you mentioned that the libstdc++ testsuite could be examined in
order to fix some of our failures.

============
GNU/debugger
============

Our gdb has no visibility upstream. I'm taking a hiatus from glibc to
fix gdb. I volunteered for this like 2 years ago, but glibc took a long
time to fix.

===============
ELF64 Userspace
===============

32-bit versus 64-bit signals are fixed. Along with ucontext and siginfo.
A good project might be for someone to implement the set/get/make/swap
context calls in userspace, takers are welcome! I will *not* be working
ELF64 yet, without a working gdb it's quite hard to do *anything*. I
just recently learned how to poke insns into binary files for
debugging... it's not as much fun as you think ;)

I need to do similar signal hacking for ia64 or upstream may never
accept my linux/kernel/* patches. Worst-case has us absorb the changes
into our arch directory and nobody else benefits from the framework :(

============================
Kernel<->Usrspace Atomic ops
============================

Will work on these whilst I hack gdb. Expect a first cut in a month or
so.

========
GNU/libc
========

I'm here to speak on behalf of the userspace work we have done. Glibc is
in *much* better shape than before, a year ago there were so many errors
I didn't know where to begin. Our current list of failures is down to:

make[2]: *** [/glibc-work/build-hppa/math/test-float.out] Error 136
make[2]: *** [/glibc-work/build-hppa/math/test-double.out] Error 1
make[2]: *** [/glibc-work/build-hppa/math/test-ifloat.out] Error 136
make[1]: *** [math/tests] Error 2

These three tests are related to the fact that we don't have long double
supported properly. Waiting on HP to release the code. An alternative is
a long double with only 64-bits, though this would be the *last* thing
on the list of userspace problems to fix (it would cement our long
double ABI at 64-bits).

make[2]: *** [/glibc-work/build-hppa/stdlib/tst-strtod.out] Error 1
make[2]: *** [/glibc-work/build-hppa/stdlib/bug-strtod.out] Error 1
make[1]: *** [stdlib/tests] Error 2

Same issue, no long double support, so string to double fails.

make[2]: *** [/glibc-work/build-hppa/dlfcn/tststatic.out] Error 139
make[1]: *** [dlfcn/tests] Error 2

The value of an address is interpreted as a function descriptor and
erroneously loads the wrong stuff during the jump. This will require a
bit more work to track down the particular PLABEL32 or IPLT relocation
causing the problem.

The trickiest bugs to remove were all those symbol visibility bugs,
which weren't related to symbol visibility at all. Infact due to our
erroneous function pointer implementation we were skipping all ld.so.1
COPY relocations. I ported hppa over to use the generic function
descriptor code and was finally able to process all of ld's COPY relocs.
I have no idea if this was ever a problem for symbols other than
_r_debug. Gdb may benefit from this.

Profiling is fixed thanks to Randolph! And I just completed the required
changes to get sprof working for shared libraries. I can finally enable
*other* people to track down elusive performance problems in shared
library code.

Aside from that we are no longer in danger of losing glibc, a few more
patches and upstream will be synchronized! I think Ulrich might be
growing to accept me as the hppa maintainer :)

Cheers,
Carlos.