Re: Register r9 in the ARM ABI

[Richard Henderson]

On 02/28/2013 11:41 PM, Niels Möller wrote:
> I have a general ARM question, that maybe Richard or someone else on the
> list can answer.
> 
>>From the ABI documentation I've read, register r9 is in some way
> reserved for implementation of things like thread local storage. If I
> write a leaf function (not calling anybody else, and not using thread
> local storage), can a use r9 like any other callee-save register or not?
> 
> The only potential problem case I see is if my function is interupted by
> a signal, and the signal handler expects the value in register r9 to be
> valid.

Roland McGrath has recently been adjusting this in glibc for Google's ARM
Na(tive)Cl(ient) ABI, so I suspect they want this register untouched all the 
time.

FWIW, it doesn't matter for Linux.  There we use CP15 for the thread pointer,
copied as needed to a core register.


r~
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel

Re: GMP symbol naming (and the history thereof)?

[Torbjorn Granlund]

Richard Henderson  writes:

  Excellent.  That's more or less exactly what I want to do.
  
That would be another welcome contribution!

  I believe that IFUNC and the "fallback" fat system can live side-by side,
  sharing most of the actual logic.  The choice of which implementation to build
  into the shared library can be made by configure.
  
Good!

  Fair enough.  While you can't override the mpn routines in libc.so (they're
  hidden), there is a potential issue with static linking.  FWIW, glibc uses
  "__mpn" as the prefix.
  
  FWIW, on another library I wrote recently I used "pfx_" for the external names
  and "PFX_" for the internal names.
  
I suggest that we do it like the following in GMP:

In a static lib, I suppose nothing should change.

In a shared lib, make all symbols by just the logical call name, like
mpn_addmul_1, mpz_mul, gmp_printf, mpn_strangeinternalfunction.  Make
these hidden.  Then for the functions we want to make public, define
aliases to __gmpn_addmul_1, __gmpz_mul, __gmp_printf.

Motivation: This should be link compatible with existing user programs.
Using the plain names internally is a convenience when debugging.

About testing of static vs shared lib.  Currently 'make check' test
either, never both, even if both were built.  I consider this a serious
flaw, since 'make check' gives a false confidence that the library was
not miscompiled.  I would like to change this behaviour.

I realise the 'hidden' project might create some problems for (unit)
testing of internal routines.  I am not sure we do that a lot, except
that tune/speed, tune/tuneup, tests/devel/try surely need access to
everything.  I see two solutions:

1. Possibly have a configure option that disables the 'hidden' stuff.

2. Link these three programs statically.  That's not at all
   unreasonable.

A side note: I think that we should move towards fat binary builds as
the "normal" build.  Our current method of careful compile-time CPU
recognition is better for benchmarking than for the real world.
Ideally, fat builds should be the default for all configs.
Unfortunately CPU manufacturers make CPU recognition difficult.

-- 
Torbjörn
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel

Re: Register r9 in the ARM ABI

[Torbjorn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  I have a general ARM question, that maybe Richard or someone else on the
  list can answer.
  
  From the ABI documentation I've read, register r9 is in some way
  reserved for implementation of things like thread local storage. If I
  write a leaf function (not calling anybody else, and not using thread
  local storage), can a use r9 like any other callee-save register or not?
  
  The only potential problem case I see is if my function is interupted by
  a signal, and the signal handler expects the value in register r9 to be
  valid.
  
One way of answering such a question is to check wat GCC does for the C
code of the same package.  Then follow the principle, "if GCC does it, I
may as well."  :-)

I'll do 'objdump -dw file-with-large-function' in this case.

But the nerdiest way of figuring out these sort of things is reading
gcc/gcc/config/arm/arm.h, so that's wat I usually do.

-- 
Torbjörn
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel