Re: RTEMS-specific Newlib patches for aarch64

2022-04-22 Thread Kinsey Moore

On 4/22/2022 07:28, Sebastian Huber wrote:

On 17/03/2022 13:30, Kinsey Moore wrote:

On 3/17/2022 05:00, Sebastian Huber wrote:

Hello,

the current Newlib build fails for aarch64 due to RTEMS-specific 
patches:


  CC   libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: 
fatal error: ../asmdefs.h: No such file or directory

   29 | #include <../asmdefs.h>
  |  ^~

Why are these patches not in upstream Newlib?

The only patch I'm aware of should be for ILP32 support in the 
hand-coded AArch64 assembly in newlib.


The short answer as to why the patch isn't upstream is that newlib 
hasn't committed it yet.


The longer answer is that the hand-coded AArch64 ASM in newlib is 
sourced from ARM's optimized-routines repository. I provided a patch 
to newlib's specifications at which point they suggested I get it 
committed upstream in the optimized-routines repo, first. I did that 
and then requested they pull the changes, but they were in the middle 
of a release cycle. Having the patch locally was the interim solution 
while we waited for that release to finish and for newlib to pull in 
the changes. I'll take a look and see what the current status on that 
is and what changes prompted the patch to break.


I don't see open pull requests in

https://github.com/ARM-software/optimized-routines/pulls

What is the status with respect to a Newlib integration?

All the necessary changes have been integrated into the 
optimized-routines repository. I just pinged the newlib list about 
integrating those changes since there doesn't seem to have been any 
movement toward that goal.



Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS-specific Newlib patches for aarch64

2022-04-22 Thread Sebastian Huber



On 17/03/2022 13:30, Kinsey Moore wrote:

On 3/17/2022 05:00, Sebastian Huber wrote:

Hello,

the current Newlib build fails for aarch64 due to RTEMS-specific patches:

  CC   libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: 
fatal error: ../asmdefs.h: No such file or directory

   29 | #include <../asmdefs.h>
  |  ^~

Why are these patches not in upstream Newlib?

The only patch I'm aware of should be for ILP32 support in the 
hand-coded AArch64 assembly in newlib.


The short answer as to why the patch isn't upstream is that newlib 
hasn't committed it yet.


The longer answer is that the hand-coded AArch64 ASM in newlib is 
sourced from ARM's optimized-routines repository. I provided a patch to 
newlib's specifications at which point they suggested I get it committed 
upstream in the optimized-routines repo, first. I did that and then 
requested they pull the changes, but they were in the middle of a 
release cycle. Having the patch locally was the interim solution while 
we waited for that release to finish and for newlib to pull in the 
changes. I'll take a look and see what the current status on that is and 
what changes prompted the patch to break.


I don't see open pull requests in

https://github.com/ARM-software/optimized-routines/pulls

What is the status with respect to a Newlib integration?

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS-specific Newlib patches for aarch64

2022-03-17 Thread Kinsey Moore

On 3/17/2022 10:43, Sebastian Huber wrote:

On 17/03/2022 16:40, Kinsey Moore wrote:

with current newlib (ed32020)


This is not the current Newlib. There are a couple of build system 
patches on top of it.


I guess the problem is that one location in the patch uses #include 
<...> and not #include "...'.


Ah, I was looking at the github repo which is perpetually stale by a 
couple of days. I'll check the most recent one and get the patch updated.



Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: RTEMS-specific Newlib patches for aarch64

2022-03-17 Thread Sebastian Huber

On 17/03/2022 16:40, Kinsey Moore wrote:

with current newlib (ed32020)


This is not the current Newlib. There are a couple of build system 
patches on top of it.


I guess the problem is that one location in the patch uses #include 
<...> and not #include "...'.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS-specific Newlib patches for aarch64

2022-03-17 Thread Kinsey Moore

On 3/17/2022 07:30, Kinsey Moore wrote:

On 3/17/2022 05:00, Sebastian Huber wrote:

Hello,

the current Newlib build fails for aarch64 due to RTEMS-specific 
patches:


  CC   libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: 
fatal error: ../asmdefs.h: No such file or directory

   29 | #include <../asmdefs.h>
  |  ^~

Why are these patches not in upstream Newlib?

The only patch I'm aware of should be for ILP32 support in the 
hand-coded AArch64 assembly in newlib.


The short answer as to why the patch isn't upstream is that newlib 
hasn't committed it yet.


The longer answer is that the hand-coded AArch64 ASM in newlib is 
sourced from ARM's optimized-routines repository. I provided a patch 
to newlib's specifications at which point they suggested I get it 
committed upstream in the optimized-routines repo, first. I did that 
and then requested they pull the changes, but they were in the middle 
of a release cycle. Having the patch locally was the interim solution 
while we waited for that release to finish and for newlib to pull in 
the changes. I'll take a look and see what the current status on that 
is and what changes prompted the patch to break.


I just rebuilt this on the current RTEMS6 GCC10 branch with current 
newlib (ed32020) and had no problems building it. It's odd that the file 
is missing given that it's newly written by the patch. What else is 
necessary to reproduce the build failure?



Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS-specific Newlib patches for aarch64

2022-03-17 Thread Kinsey Moore

On 3/17/2022 05:00, Sebastian Huber wrote:

Hello,

the current Newlib build fails for aarch64 due to RTEMS-specific patches:

  CC   libc/string/libc_a-wcscmp.o
../../../gnu-mirror-gcc-0f001dd/newlib/libc/machine/aarch64/setjmp.S:29:10: 
fatal error: ../asmdefs.h: No such file or directory

   29 | #include <../asmdefs.h>
  |  ^~

Why are these patches not in upstream Newlib?

The only patch I'm aware of should be for ILP32 support in the 
hand-coded AArch64 assembly in newlib.


The short answer as to why the patch isn't upstream is that newlib 
hasn't committed it yet.


The longer answer is that the hand-coded AArch64 ASM in newlib is 
sourced from ARM's optimized-routines repository. I provided a patch to 
newlib's specifications at which point they suggested I get it committed 
upstream in the optimized-routines repo, first. I did that and then 
requested they pull the changes, but they were in the middle of a 
release cycle. Having the patch locally was the interim solution while 
we waited for that release to finish and for newlib to pull in the 
changes. I'll take a look and see what the current status on that is and 
what changes prompted the patch to break.



Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel