[parisc-linux] 64 userspace

[parisc-linux] 64 userspace

[FARINATI,LEANDRO (HP-Brazil,ex1)]

	Hi people,

	Where am I find the to do list to 64 userspace (to compile 64 bits
applications)?

	Thanks in advance,

-----------------------------------------------------------------------
              Leandro Marcondes Farinati
                    Software Developer

*   leandro.farinati@hp.com

Re: [parisc-linux] 64 userspace

[John David Anglin]

> 	Hi people,
> 
> 	Where am I find the to do list to 64 userspace (to compile 64 bits
> applications)?

To my knowledge, there isn't one.  Roughly what is required is:

1) Kernel -- design and implement 64-bit system calls.

2) Binutils -- port hpux 64-bit tools to linux.

3) Gdb -- same as binutils.

4) GCC --  same as binutils.

5) Glibc -- implement 64-bit specific parts of ABI and system calls.

The ABI hasn't been discussed in detail other than it was to be generally
similar to that used under 64-bit hpux.   There are significant differences
between 64-bit hpux and 32-bit linux.  They use different linkers and
differ in the handling of function pointers.  The 32-bit linker was
ported from the 386 code while the 64-bit linker used by hpux was written
from scratch.  As a result, the 64-bit code is less tested and has more bugs.

Are you offering support from HP?  It's taken a number of years to
get to the current state of development on the 32-bit port given the
level of volunteer effort and support from HP.  What you are asking
won't happen for months, if not years.  The time to implement a 64-bit
userspace won't be as great as for the 32-bit port, but it still a
very significant effort.

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

Re: [parisc-linux] 64 userspace

[Matthew Wilcox]

On Wed, Jan 15, 2003 at 01:40:28PM -0500, John David Anglin wrote:
> To my knowledge, there isn't one.  Roughly what is required is:
> 
> 1) Kernel -- design and implement 64-bit system calls.

Another piece of the kernelside puzzle is designing the VM layout for
64-bit processes.  Do we want to (as ia64 does) reserve parts of the address
space for the kernel?  Map shared libraries in different quadrants from
the user process?  Keep data in yet another quadrant?

It's a lot of work, and I'm not sure the will is there to make it happen.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] 64 userspace

[Carlos O'Donell]

> > 1) Kernel -- design and implement 64-bit system calls.
> 
> Another piece of the kernelside puzzle is designing the VM layout for
> 64-bit processes.  Do we want to (as ia64 does) reserve parts of the address
> space for the kernel?  Map shared libraries in different quadrants from
> the user process?  Keep data in yet another quadrant?
> 
> It's a lot of work, and I'm not sure the will is there to make it happen.
> 

We are swamped with a 32-bit userspace, and 32/64-bit kernel, creating a
full 64-bit userspace is extremely difficult. I'm currently trying to
workout the bits to get a static 64-bit Glibc, though currently fixing
the 32-bit Glibc we have is time consuming enough.

c.

Re: [parisc-linux] 64 userspace

[Carlos O'Donell]

> To my knowledge, there isn't one.  Roughly what is required is:
> 
> 1) Kernel -- design and implement 64-bit system calls.

Currently, 64-bit kernels return bogus sigcontext structures to our
32-bit userspace, they stuff the sigcontext with 64-bit registers when
it is only expecting 32-bits. It seems like sigcontext should be
expanded to have 64-bits per register for both 32 and 64 bit kernels?
This is definately an ABI breakage. Though it's funny that not many
programs are broken under 64-bit kernels, but I guess that without
*context() calls implemented for HPPA in glibc, the returned ucontext is
not used (except for that weird LISP interpreter that Krystof was
porting).
 
> 2) Binutils -- port hpux 64-bit tools to linux.

I thought we had a 64-bit binutils port?

> 3) Gdb -- same as binutils.

This would require some work.

> 4) GCC --  same as binutils.

hppa64-linux-gcc?

> 5) Glibc -- implement 64-bit specific parts of ABI and system calls.

This is a biggie, 64-bit SHLIBS being the large headache.

> Are you offering support from HP?  It's taken a number of years to
> get to the current state of development on the 32-bit port given the
> level of volunteer effort and support from HP.  What you are asking
> won't happen for months, if not years.  The time to implement a 64-bit
> userspace won't be as great as for the 32-bit port, but it still a
> very significant effort.

Perhaps we will see it's emergence in the next few years :)

c.

Re: [parisc-linux] 64 userspace

[John David Anglin]

> > To my knowledge, there isn't one.  Roughly what is required is:
> > 
> > 1) Kernel -- design and implement 64-bit system calls.
> 
> Currently, 64-bit kernels return bogus sigcontext structures to our
> 32-bit userspace, they stuff the sigcontext with 64-bit registers when
> it is only expecting 32-bits. It seems like sigcontext should be
> expanded to have 64-bits per register for both 32 and 64 bit kernels?
> This is definately an ABI breakage. Though it's funny that not many
> programs are broken under 64-bit kernels, but I guess that without
> *context() calls implemented for HPPA in glibc, the returned ucontext is
> not used (except for that weird LISP interpreter that Krystof was
> porting).

I wonder if this isn't the problem with expect.

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

Re: [parisc-linux] 64 userspace

[Carlos O'Donell]

> > > 1) Kernel -- design and implement 64-bit system calls.
> > 
> > Currently, 64-bit kernels return bogus sigcontext structures to our
> > 32-bit userspace, they stuff the sigcontext with 64-bit registers when
> > it is only expecting 32-bits. It seems like sigcontext should be
> > expanded to have 64-bits per register for both 32 and 64 bit kernels?
> > This is definately an ABI breakage. Though it's funny that not many
> > programs are broken under 64-bit kernels, but I guess that without
> > *context() calls implemented for HPPA in glibc, the returned ucontext is
> > not used (except for that weird LISP interpreter that Krystof was
> > porting).
> 
> I wonder if this isn't the problem with expect.
> 

Shazam! Ballz in your court. I ran across this problem in the summer
when working with Krystof. He actually caused my C3K to crash, different
issue though :}

If you look at parisc/kernel/signal.c and look for the word "HACK"
you'll see what I mean. There are few expletives that need to be cleaned
up. Randolph had suggested adding thread personalities so we can tell
what the userspace looks like and choose the right sigcontext to send
back. However, it seems that truncating the 64-bit regs is a crazy thing
to do since you might lose information.

I'm all for expanding the sigcontext to 64-bits. As a matter of fact
I'll try rebuilding glibc with an expanded sigcontext (remembering that
it has to be changed in the kernel definition and the glibc definition).
Added to that will be the minor hack to your ldwc_align code to fdce the
lock cacheline before usage.

c.

Re: [parisc-linux] 64 userspace

[Carlos O'Donell]

> 
> I wonder if this isn't the problem with expect.
> 
> Dave

On another note, if expect calls code that uses atomic_add,
compare_and_swap, and exchange_and_add, they are currently generic and
not guaranteed to be atomic under any situation.

See atomicity.h.

Damn, I should really get around to implementing these.

c.

Re: [parisc-linux] 64 userspace

[John David Anglin]

> > I wonder if this isn't the problem with expect.
> > 
> > Dave
> 
> On another note, if expect calls code that uses atomic_add,
> compare_and_swap, and exchange_and_add, they are currently generic and
> not guaranteed to be atomic under any situation.
> 
> See atomicity.h.

I doubt it.  It does a lot of waiting around with alarm signals going off.
As I recall, when it is filling the syslog, there are two expect processes
running and killing the child fixes the problem.  This causes dejagnu to
abort the current testsuite.

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

Re: [parisc-linux] 64 userspace

[John David Anglin]

> > 2) Binutils -- port hpux 64-bit tools to linux.
> 
> I thought we had a 64-bit binutils port?

There enough to build kernels, static binaries, ...  The linker is really
the problem.  First, we would need the processor/os specific ELF
specification.  The handling of function pointers is another key part
as it affects how shared libraries are implemented and the dynamic loader.

I don't see the gcc issues as major as we have the code generation part
pretty much under control.

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

Re: [parisc-linux] 64 userspace

[Carlos O'Donell]

> > I thought we had a 64-bit binutils port?
> 
> There enough to build kernels, static binaries, ...  The linker is really
> the problem.  First, we would need the processor/os specific ELF
> specification.  The handling of function pointers is another key part
> as it affects how shared libraries are implemented and the dynamic loader.

Okay. Were on the same page :)
 
> I don't see the gcc issues as major as we have the code generation part
> pretty much under control.

Yup :)

c.