[parisc-linux] where to put 64 bit libmilli?

[parisc-linux] where to put 64 bit libmilli?

[Paul Bame]

I have source code for HP's 64-bit millicode and am working on making
it compilable with our tool chain.  But the bigger question is where
do I put it?

Right now millicode is part of libgcc.a in top-of-branch gcc, but I
seem to recall some linker magic, and when/if that happens I don't
know where to put the millicode stuff.

Help?

	-Paul Bame

Re: [parisc-linux] where to put 64 bit libmilli?

[John David Anglin]

> I have source code for HP's 64-bit millicode and am working on making
> it compilable with our tool chain.  But the bigger question is where
> do I put it?
> 
> Right now millicode is part of libgcc.a in top-of-branch gcc, but I
> seem to recall some linker magic, and when/if that happens I don't
> know where to put the millicode stuff.

Last time I looked the 64 bit port was still using the same milli
library as the 32 bit port.  Thus to integrate a 64 bit library,
some work would have to be done to the machine description.  There
are hooks to build asm code (see for example lib1funcs.asm and
lib2funcs.asm in config/pa).

Has HP contributed this code to the public domain?  Probably, Jeff
Law would be the one to contact to get integrated into the gcc mainline.

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

Re: [parisc-linux] where to put 64 bit libmilli?

[Paul Bame]

= Last time I looked the 64 bit port was still using the same milli
= library as the 32 bit port.

Yes -- leading to some very surprising 64-bit kernel failures
before I found this "feature".  This is a 64-bit parisc linux gcc bug.

= Thus to integrate a 64 bit library,
= some work would have to be done to the machine description.  There
= are hooks to build asm code (see for example lib1funcs.asm and
= lib2funcs.asm in config/pa).

I've played with this a bit before -- I did the first ELF version of
of 32-bit millicode.  But I'm not at all certain we want to
keep millicode in libgcc.a since there's also some parisc linker magic to
automatically link millicode when required -- because some makefiles
using ld -r break (like the Linux kernel build) unless they're hacked to
include an explicit reference to libgcc.a.

= Has HP contributed this code to the public domain?  Probably, Jeff
= Law would be the one to contact to get integrated into the gcc mainline.

I have permission to sanitize and (L?)GPLize it.  I'm planning to
attempt the basic integration and then let Jeff or someone tell me
how I screwed it up :-)

	-Paul Bame

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <E14DXa6-0005xq-00@noam.fc.hp.com>you write:
  > I have permission to sanitize and (L?)GPLize it.  I'm planning to
  > attempt the basic integration and then let Jeff or someone tell me
  > how I screwed it up :-)
BTW, if you dig around the GCC CVS tree, you'll find 32bit millicode ready
to work with GNU tools. (gcc/config/pa/lib1funcs.asm)  I don't know if that
would be useful to you or not.

Moving it out of libgcc may or may not make sense.  If I recall the key thing
to remember is that you want copies of those routines in each shared library,
otherwise you can lose in unpleasant ways.  An alternative is to make the
millicode routines themselves into a shared library and everyone links against.

jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Tue, 2 Jan 2001, Jeffrey A Law wrote:

> Moving it out of libgcc may or may not make sense.  If I recall the key thing
> to remember is that you want copies of those routines in each shared library,
> otherwise you can lose in unpleasant ways.  An alternative is to make the
> millicode routines themselves into a shared library and everyone links against.

The real reason that we currently need separate millicode routines for
each shared lib is that linkage to millicode functions is different than
for normal functions.  In particular, you don't want to load r19 (32 bit
case) or r27 (64 bit case) when calling millicode.  Therefore, a shared
millicode lib would require special .plt entries.  Not too hard to do,
just a bit messy.

Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[Matthew Wilcox]

On Wed, Jan 03, 2001 at 12:46:52PM +1100, Alan Modra wrote:
> The real reason that we currently need separate millicode routines for
> each shared lib is that linkage to millicode functions is different than
> for normal functions.  In particular, you don't want to load r19 (32 bit

is there a good reason to keep the millicode calling conventions?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Wed, 3 Jan 2001, Matthew Wilcox wrote:

> is there a good reason to keep the millicode calling conventions?

It's faster and doesn't require that gcc reload gp.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <Pine.LNX.4.21.0101031235310.24351-100000@front.linuxcare.com.au>y
ou write:
  > The real reason that we currently need separate millicode routines for
  > each shared lib is that linkage to millicode functions is different than
  > for normal functions.  In particular, you don't want to load r19 (32 bit
  > case) or r27 (64 bit case) when calling millicode.  Therefore, a shared
  > millicode lib would require special .plt entries.  Not too hard to do,
  > just a bit messy.
So what happens in this case.

Pretend shared library A references $$div from the millicode routines.  Also
assume that the main program does not reference $$div.  Also assume that
the shared library is _not_ referenced on the link line for the main
program, but instead is sucked in via dl_open calls.

The shared library will have an undefined reference for $$div which can't
be satisfied and will terminate the application if we execute a path in
the shared library which calls $$div.


jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Tue, 2 Jan 2001, Jeffrey A Law wrote:

> 
> 
>   In message <Pine.LNX.4.21.0101031235310.24351-100000@front.linuxcare.com.au>y
> ou write:
>   > The real reason that we currently need separate millicode routines for
>   > each shared lib is that linkage to millicode functions is different than
>   > for normal functions.  In particular, you don't want to load r19 (32 bit
>   > case) or r27 (64 bit case) when calling millicode.  Therefore, a shared
>   > millicode lib would require special .plt entries.  Not too hard to do,
>   > just a bit messy.
> So what happens in this case.
> 
> Pretend shared library A references $$div from the millicode routines.  Also
> assume that the main program does not reference $$div.  Also assume that
> the shared library is _not_ referenced on the link line for the main
> program, but instead is sucked in via dl_open calls.

Ah, but that's where the automagic linker search for libmilli come into
play.  Effectively, libmilli is always mentioned on the "command line"

> The shared library will have an undefined reference for $$div which can't
> be satisfied and will terminate the application if we execute a path in
> the shared library which calls $$div.
> 
> 
> jeff
> 

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <Pine.LNX.4.21.0101031509470.24351-100000@front.linuxcare.com.au>y
ou write:
  > Ah, but that's where the automagic linker search for libmilli come into
  > play.  Effectively, libmilli is always mentioned on the "command line"
Does this automagic search also happen when you build shared libraries?

[ Yes, I'm very familiar with HP's automagic searching for libmilli.a.  I also
  think it's a terrible mistake as a design decision. ]

jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Tue, 2 Jan 2001, Jeffrey A Law wrote:

>   In message <Pine.LNX.4.21.0101031509470.24351-100000@front.linuxcare.com.au>y
> ou write:
>   > Ah, but that's where the automagic linker search for libmilli come into
>   > play.  Effectively, libmilli is always mentioned on the "command line"
> Does this automagic search also happen when you build shared libraries?

Yes.  shared libs thus get their own copy of millicode routines.

> [ Yes, I'm very familiar with HP's automagic searching for libmilli.a.  I also
>   think it's a terrible mistake as a design decision. ]

I'm not particularly enthusiastic about the idea either.  It seemed to be
the best solution in the face of a number of packages that "know" libgcc
isn't needed when linking certain programs.  eg. linux kernel, binutils
testsuite.  The alternatives are
  a) fix all the affected packages
  b) modify linker scripts
  c) magic inbuilt linker behaviour.

a) has the unfortunate effect of making hppa seem like the ugly duckling,
at least until all affected packages on the planet are fixed.
b) doesn't work with custom linker scripts.

I'm all ears for a better solution.

Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <Pine.LNX.4.21.0101031532370.24351-100000@front.linuxcare.com.au>y
  > I'm not particularly enthusiastic about the idea either.  It seemed to be
  > the best solution in the face of a number of packages that "know" libgcc
  > isn't needed when linking certain programs.  eg. linux kernel, binutils
  > testsuite.  The alternatives are
  >   a) fix all the affected packages
  >   b) modify linker scripts
  >   c) magic inbuilt linker behaviour.
But I would consider those very special cases and wouldn't want to pollute
the linker to work around those special cases.

The easiest (to me) solution is to put the routines into the system C
library.  You'd drop the special millcode conventions, but that's a
small price given that the only ones you probably call with any
regularity are div/mod in which case the cost of reloading the pic
registers is dwarfed by cost of the divide.

Then for the kernel you just put the needed routines (probably just
$$div, $$divU, $$rem, $$remU) into arch/parisc/support.S.

jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Wed, 3 Jan 2001, Jeffrey A Law wrote:

> The easiest (to me) solution is to put the routines into the system C
> library.  You'd drop the special millcode conventions, but that's a

How about $$dyncall?  Wouldn't loading r19/r29 break this function?  I'm
thinking of the case where $$dyncall is passed the address of a local
function rather than a plabel.  We wouldn't want to load r19/r29 with the
value for a shared libgcc.

> small price given that the only ones you probably call with any
> regularity are div/mod in which case the cost of reloading the pic
> registers is dwarfed by cost of the divide.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[John David Anglin]

> On Wed, 3 Jan 2001, Jeffrey A Law wrote:
> 
> > The easiest (to me) solution is to put the routines into the system C
> > library.  You'd drop the special millcode conventions, but that's a
> 
> How about $$dyncall?  Wouldn't loading r19/r29 break this function?  I'm
> thinking of the case where $$dyncall is passed the address of a local
> function rather than a plabel.  We wouldn't want to load r19/r29 with the
> value for a shared libgcc.

Could this and maybe some of the other short milli routines be compiler
"builtins"?  This would allow inlining.

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

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Thu, 4 Jan 2001, John David Anglin wrote:

>[about $$dyncall]
> Could this and maybe some of the other short milli routines be compiler
> "builtins"?  This would allow inlining.

I don't see why not.  It could be done by expanding all the $$dyncall
references in pa.c and pa.md

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[Paul Bame]

For hppa64-linux it appears the only millicode we're using is $$div*
and $$rem*, not $$dyncall nor $sh_func_adrs.  Let me know if I should
be porting anything other thatn div/rem -- thanks.

	-Paul Bame

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <E14EDNR-00024o-00@noam.fc.hp.com>you write:
  > 
  > For hppa64-linux it appears the only millicode we're using is $$div*
  > and $$rem*, not $$dyncall nor $sh_func_adrs.  Let me know if I should
  > be porting anything other thatn div/rem -- thanks.
That sounds correct to me.  The PA64 calling conventions don't need
$$dyncall or $sh_func_addrs.

jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <200101040618.BAA05609@hiauly1.hia.nrc.ca>you write:
  > > How about $$dyncall?  Wouldn't loading r19/r29 break this function?  I'm
  > > thinking of the case where $$dyncall is passed the address of a local
  > > function rather than a plabel.  We wouldn't want to load r19/r29 with the
  > > value for a shared libgcc.
  > 
  > Could this and maybe some of the other short milli routines be compiler
  > "builtins"?  This would allow inlining.
Yes, though it's not clear how much of a win it is for PA32, it might even
be a loss.  Hard to guess.  Someone would have to benchmark it.

For PA64 the indirect calling sequence is significantly simpler and is
emitted inline, hence we don't need/use $$dyncall for PA64.

jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Jeffrey A Law]

  In message <Pine.LNX.4.21.0101041608490.15554-100000@front.linuxcare.com.au>y
ou write:
  > On Wed, 3 Jan 2001, Jeffrey A Law wrote:
  > 
  > > The easiest (to me) solution is to put the routines into the system C
  > > library.  You'd drop the special millcode conventions, but that's a
  > 
  > How about $$dyncall?  Wouldn't loading r19/r29 break this function?  I'm
  > thinking of the case where $$dyncall is passed the address of a local
  > function rather than a plabel.  We wouldn't want to load r19/r29 with the
  > value for a shared libgcc.
$$dyncall is only used for PA32 -- what ABI are you using for PA32?  The
existing ones don't require $dp or $gp to be loaded by the caller -- they're
handled in the stub between the caller & callee.


jeff

Re: [parisc-linux] where to put 64 bit libmilli?

[Paul Bame]

FYI I just committed the 64-bit millicode to the CVS on
puffin.external.hp.com adding it to libgcc.a as with 32-bit parisc gcc.

Re: [parisc-linux] where to put 64 bit libmilli?

[Alan Modra]

On Thu, 4 Jan 2001, Jeffrey A Law wrote:

>   In message <Pine.LNX.4.21.0101041608490.15554-100000@front.linuxcare.com.au>y
> ou write:
>   > On Wed, 3 Jan 2001, Jeffrey A Law wrote:
>   > 
>   > > The easiest (to me) solution is to put the routines into the system C
>   > > library.  You'd drop the special millcode conventions, but that's a
>   > 
>   > How about $$dyncall?  Wouldn't loading r19/r29 break this function?  I'm
>   > thinking of the case where $$dyncall is passed the address of a local
>   > function rather than a plabel.  We wouldn't want to load r19/r29 with the
>   > value for a shared libgcc.
> $$dyncall is only used for PA32 -- what ABI are you using for PA32?  The
> existing ones don't require $dp or $gp to be loaded by the caller -- they're
> handled in the stub between the caller & callee.

The ABI hasn't changed.  r19 is loaded by the stub for a call into a
shared lib function.  That's a problem if we ever wanted to put $$dyncall
into a shared lib and make it available externally, as this particular
call should _not_ load r19.  ie. At least for $$dyncall, we can't use
standard hppa calling conventions.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] where to put 64 bit libmilli?

[Cary Coutant]

>For PA64 the indirect calling sequence is significantly simpler and is
>emitted inline, hence we don't need/use $$dyncall for PA64.

Even for PA-32, $$dyncall should be simple enough to emit inline. There 
were two reasons why we didn't do it at first:

1. Our compilers emitted code that was compatible with both MPE and 
HP-UX. Since function pointers had different representations in these two 
runtimes, $$dyncall had to check a low-order bit.

2. After we implemented shared libraries on HP-UX, function pointers 
could be either "internal" or "external", and $$dyncall had to check.

Eventually, HP-UX has moved to a runtime where function pointers are 
either all internal (for a statically-bound program) or all external (for 
a dynamically-bound program). We now have compiler options to generate 
the appropriate inline sequence for either model.

Linux shouldn't need to be concerned with either of these cases. If 
you're using $$dyncall for the 32-bit runtime, I strongly suggest that 
you change the compiler.

-cary

Re: [parisc-linux] where to put 64 bit libmilli?

[Grant Grundler]

Cary Coutant wrote:
> Linux shouldn't need to be concerned with either of these cases. If 
> you're using $$dyncall for the 32-bit runtime, I strongly suggest that 
> you change the compiler.

Where does support for HPUX built apps fit into the picture?

I thought a long term goal is to support HPUX built apps to run under
parisc-linux. Eg it would be really cool if we could run the HPUX
X11 server...

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] where to put 64 bit libmilli?

[Cary Coutant]

>Where does support for HPUX built apps fit into the picture?
>
>I thought a long term goal is to support HPUX built apps to run under
>parisc-linux. Eg it would be really cool if we could run the HPUX
>X11 server...

If they're built on HP-UX, they will already have been linked with the 
HP-UX millicode library.

-cary