__ieee754_lgamma_r reentrency with nano.specs

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

__ieee754_lgamma_r reentrency with nano.specs

Damien Nicolet
Hi,

I have an issue when using __ieee754_lgamma_r (through lgamma) together
with nano.specs. I think libm is compiled referencing the full struct
_reent and thus a call to lgamma overwrites memory out of the small struct
_reent used by libc_nano.

I'm using newlib on an stm32 from debian sid libnewlib-arm-none-eabi
package, but I also have the problem with ARM provided toolchain
(gcc-arm-none-eabi-8-2019-q3-update).

I don't know if it is the right place to submit this kind of problem. If it
is, I can provide more information or even some code showing the issue if
needed.

Damien
Reply | Threaded
Open this post in threaded view
|

Re: __ieee754_lgamma_r reentrency with nano.specs

Keith Packard
Damien Nicolet <[hidden email]> writes:

> I'm using newlib on an stm32 from debian sid libnewlib-arm-none-eabi
> package, but I also have the problem with ARM provided toolchain
> (gcc-arm-none-eabi-8-2019-q3-update).

Are you using the libnewlib-nano-arm-none-eabi package, or the
libnewlib-arm-none-eabi package? I package the smaller one
(libnewlib-nano-arm-none-eabi), and that is built from a different tree
with many changes, which would make cross-linking fail. Given the
potential for confusion, the smaller one has been renamed 'picolibc'.

Remember to get your include paths and library paths set correctly so
that you get headers and libraries that match, and that match the
compiler arguments you're using to build your code.

--
-keith

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: __ieee754_lgamma_r reentrency with nano.specs

Damien Nicolet
>
> > I'm using newlib on an stm32 from debian sid libnewlib-arm-none-eabi
> > package, but I also have the problem with ARM provided toolchain
> > (gcc-arm-none-eabi-8-2019-q3-update).
>
> Are you using the libnewlib-nano-arm-none-eabi package, or the
> libnewlib-arm-none-eabi package?


I'm using the libnewlib-arm-none-eabi. Nothing fancy, just
"--specs=nano.specs" in CFGLAG and LDFLAGS, and "-lm" in LDFLAGS.


> I package the smaller one
> (libnewlib-nano-arm-none-eabi), and that is built from a different tree
> with many changes, which would make cross-linking fail. Given the
> potential for confusion, the smaller one has been renamed 'picolibc'.
>

I tried libnewlib-nano-arm-none-eabi debian package. The version of
picolibc in it is a little bit old and missing some functionalities (sbrk
and _ios) that were added in the current git version. The git version is
very easy to use (thanks to picolibc.specs), but I have some trouble cross
compiling a dependency with it for now.


> Remember to get your include paths and library paths set correctly so
> that you get headers and libraries that match, and that match the
> compiler arguments you're using to build your code.
>

I think I'm doing it correctly. Maybe I am missing something, but I don't
see any specific version of libm using the small struct _reent for signgam
in __ieee754_lgamma_r when used with nano.specs. I will try to put together
a small example of the problem.

Damien
Reply | Threaded
Open this post in threaded view
|

Re: __ieee754_lgamma_r reentrency with nano.specs

Keith Packard
Damien Nicolet <[hidden email]> writes:

> I tried libnewlib-nano-arm-none-eabi debian package. The version of
> picolibc in it is a little bit old and missing some functionalities (sbrk
> and _ios) that were added in the current git version. The git version is
> very easy to use (thanks to picolibc.specs), but I have some trouble cross
> compiling a dependency with it for now.

I hope that picolibc will escape the Debian new queue before too long;
there are a number of packages which want to depend on it that are
blocked by this delay.

I'm hoping to finish up a new release of picolibc in the near term; I'm
busy getting the copyright and license bits sorted out --
COPYING.NEWLIB, which is the basis of the Debian package copyright
information, is somewhat inaccurate and needs to be corrected so that
picolibc has accurate licensing information included.

> I think I'm doing it correctly. Maybe I am missing something, but I don't
> see any specific version of libm using the small struct _reent for signgam
> in __ieee754_lgamma_r when used with nano.specs. I will try to put together
> a small example of the problem.

I think you've hit on the problem -- nano.specs replaces only libc,
libg, librdimon, libstd++ and libsupc++ with nano versions.

To resolve this, you will need to build newlib yourself so that you get
libc and libm that match.

--
-keith

signature.asc (847 bytes) Download Attachment