[PATCH 0/2] Fixes for old version NetBSD targets

[PATCH 0/2] Fixes for old version NetBSD targets

[Maciej W. Rozycki]

Hi,

 In the course of my recent VAX backend modernisation effort I originally 
tried the initial version of the VAX/NetBSD port that provided ELF file 
format support, specifically 1.6.2, which at least in theory we aim to 
support with the `vax-netbsdelf' target.  That indeed turned out to be a 
theory as a couple of features we support is unconditionally enabled for 
NetBSD targets, however not really supported causing GCC compilation to 
fail in libgcc/ and libada/ respectively.

 Now we may not care that much about old NetBSD versions and I have since 
switched to NetBSD 9, but fixes are trivial enough up to the point of 
being one-liners and might make someone's life easier, so I decided to 
offer them anyway.  Compiler's functionality is limited with NetBSD 1.6.2 
and gnatlib does not build anyway for the VAX port due to missing target 
bindings, but libgcc does and the resulting cross-compiler is functional 
enough to run the test suite on actual VAX hardware (although the NetBSD 
kernel that old turned out to miss a key feature needed by me to run 
testing in a feasible manner).  And I imagine gnatlib can be built for 
other NetBSD ports (missing VAX/NetBSD bindings can be easily added).

 OK to apply then?

  Maciej

[PATCH 1/2] NetBSD/libgcc: Check for TARGET_DL_ITERATE_PHDR in the unwinder

[Maciej W. Rozycki]

Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions, 
fixing compilation errors:

.../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
   75 | # define ElfW(type) Elf_##type
      |                     ^~~~
.../libgcc/unwind-dw2-fde-dip.c:132:9: note: in expansion of macro 'ElfW'
  132 |   const ElfW(Phdr) *p_eh_frame_hdr;
      |         ^~~~
.../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
   75 | # define ElfW(type) Elf_##type
      |                     ^~~~
.../libgcc/unwind-dw2-fde-dip.c:133:9: note: in expansion of macro 'ElfW'
  133 |   const ElfW(Phdr) *p_dynamic;
      |         ^~~~
.../libgcc/unwind-dw2-fde-dip.c:165:37: warning: 'struct dl_phdr_info' declared inside parameter list will not be visible outside of this definition or declaration
  165 | _Unwind_IteratePhdrCallback (struct dl_phdr_info *info, size_t size, void *ptr)
      |                                     ^~~~~~~~~~~~
[...]

and producing a working cross-compiler at least with VAX/NetBSD 1.6.2.

	libgcc/
	* unwind-dw2-fde-dip.c [__OpenBSD__ || __NetBSD__] 
	(USE_PT_GNU_EH_FRAME): Do not define if !TARGET_DL_ITERATE_PHDR.
---
 libgcc/unwind-dw2-fde-dip.c |    1 +
 1 file changed, 1 insertion(+)

gcc-netbsd-libgcc-target-dl-iterate-phdr.diff
Index: gcc/libgcc/unwind-dw2-fde-dip.c
===================================================================
--- gcc.orig/libgcc/unwind-dw2-fde-dip.c
+++ gcc/libgcc/unwind-dw2-fde-dip.c
@@ -71,6 +71,7 @@
 #endif
 
 #if !defined(inhibit_libc) && defined(HAVE_LD_EH_FRAME_HDR) \
+    && defined(TARGET_DL_ITERATE_PHDR) \
     && (defined(__OpenBSD__) || defined(__NetBSD__))
 # define ElfW(type) Elf_##type
 # define USE_PT_GNU_EH_FRAME

Re: [PATCH 1/2] NetBSD/libgcc: Check for TARGET_DL_ITERATE_PHDR in the unwinder

[Jeff Law]

On 11/15/20 10:44 AM, Maciej W. Rozycki wrote:
> Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions, 
> fixing compilation errors:
>
> .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
>    75 | # define ElfW(type) Elf_##type
>       |                     ^~~~
> .../libgcc/unwind-dw2-fde-dip.c:132:9: note: in expansion of macro 'ElfW'
>   132 |   const ElfW(Phdr) *p_eh_frame_hdr;
>       |         ^~~~
> .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
>    75 | # define ElfW(type) Elf_##type
>       |                     ^~~~
> .../libgcc/unwind-dw2-fde-dip.c:133:9: note: in expansion of macro 'ElfW'
>   133 |   const ElfW(Phdr) *p_dynamic;
>       |         ^~~~
> .../libgcc/unwind-dw2-fde-dip.c:165:37: warning: 'struct dl_phdr_info' declared inside parameter list will not be visible outside of this definition or declaration
>   165 | _Unwind_IteratePhdrCallback (struct dl_phdr_info *info, size_t size, void *ptr)
>       |                                     ^~~~~~~~~~~~
> [...]
>
> and producing a working cross-compiler at least with VAX/NetBSD 1.6.2.
>
> 	libgcc/
> 	* unwind-dw2-fde-dip.c [__OpenBSD__ || __NetBSD__] 
> 	(USE_PT_GNU_EH_FRAME): Do not define if !TARGET_DL_ITERATE_PHDR.
OK
jeff

Re: [PATCH 1/2] NetBSD/libgcc: Check for TARGET_DL_ITERATE_PHDR in the unwinder

[Maciej W. Rozycki]

On Mon, 16 Nov 2020, Jeff Law wrote:

> > 	libgcc/
> > 	* unwind-dw2-fde-dip.c [__OpenBSD__ || __NetBSD__] 
> > 	(USE_PT_GNU_EH_FRAME): Do not define if !TARGET_DL_ITERATE_PHDR.
> OK

 Committed now, thank you for your review.

  Maciej

[PATCH 2/2] libada: Check for the presence of _SC_NPROCESSORS_ONLN

[Maciej W. Rozycki]

Check for the presence of _SC_NPROCESSORS_ONLN rather than using it 
unconditionally with `sysconf', fixing a compilation error:

adaint.c: In function '__gnat_number_of_cpus':
adaint.c:2398:26: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function)
 2398 |   cores = (int) sysconf (_SC_NPROCESSORS_ONLN);
      |                          ^~~~~~~~~~~~~~~~~~~~
adaint.c:2398:26: note: each undeclared identifier is reported only once for each function it appears in

at least with with VAX/NetBSD 1.6.2.  Assume _SC_NPROCESSORS_ONLN is a 
macro and use #ifdef like in other places across GCC sources.

	gcc/ada/
	* adaint.c (__gnat_number_of_cpus): Check for the presence of 
	_SC_NPROCESSORS_ONLN before using it.
---
NB we could probably replace the list of OS #ifdefs with just a check for 
_SC_NPROCESSORS_ONLN, making use of it automagically with any new OS that 
supports it, as from the length of the list has grown up to I gather the 
`sysconf' API for this variable has become a semi-established standard now 
even though not actually listed by the relevant standards.
---
 gcc/ada/adaint.c |    2 ++
 1 file changed, 2 insertions(+)

gcc-netbsd-libada-sc-nprocessors-onln.diff
Index: gcc/gcc/ada/adaint.c
===================================================================
--- gcc.orig/gcc/ada/adaint.c
+++ gcc/gcc/ada/adaint.c
@@ -2479,7 +2479,9 @@ __gnat_number_of_cpus (void)
 #if defined (__linux__) || defined (__sun__) || defined (_AIX) \
   || defined (__APPLE__) || defined (__FreeBSD__) || defined (__OpenBSD__) \
   || defined (__DragonFly__) || defined (__NetBSD__)
+#ifdef _SC_NPROCESSORS_ONLN
   cores = (int) sysconf (_SC_NPROCESSORS_ONLN);
+#endif
 
 #elif defined (__QNX__)
   cores = (int) _syspage_ptr->num_cpu;

Re: [PATCH 2/2] libada: Check for the presence of _SC_NPROCESSORS_ONLN

[Arnaud Charlet]

> 	gcc/ada/
> 	* adaint.c (__gnat_number_of_cpus): Check for the presence of 
> 	_SC_NPROCESSORS_ONLN before using it.
> ---
> NB we could probably replace the list of OS #ifdefs with just a check for 
> _SC_NPROCESSORS_ONLN, making use of it automagically with any new OS that 
> supports it, as from the length of the list has grown up to I gather the 
> `sysconf' API for this variable has become a semi-established standard now 
> even though not actually listed by the relevant standards.

Indeed, so a better patch would be to use

#if defined (_SC_NPROCESSORS_ONLN)

instead as you noted, so let's do that.

Arno

[committed v2 2/2] libada: Check for the presence of _SC_NPROCESSORS_ONLN

[Maciej W. Rozycki]

Check for the presence of _SC_NPROCESSORS_ONLN rather than using a list 
of OS-specific macros to decide whether to use `sysconf' like elsewhere 
across GCC sources, fixing a compilation error:

adaint.c: In function '__gnat_number_of_cpus':
adaint.c:2398:26: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this function)
 2398 |   cores = (int) sysconf (_SC_NPROCESSORS_ONLN);
      |                          ^~~~~~~~~~~~~~~~~~~~
adaint.c:2398:26: note: each undeclared identifier is reported only once for each function it appears in

at least with with VAX/NetBSD 1.6.2.

	gcc/ada/
	* adaint.c (__gnat_number_of_cpus): Check for the presence of 
	_SC_NPROCESSORS_ONLN rather than a list of OS-specific macros
	to decide whether to use `sysconf'.
---
On Sun, 15 Nov 2020, Arnaud Charlet wrote:

> > NB we could probably replace the list of OS #ifdefs with just a check for 
> > _SC_NPROCESSORS_ONLN, making use of it automagically with any new OS that 
> > supports it, as from the length of the list has grown up to I gather the 
> > `sysconf' API for this variable has become a semi-established standard now 
> > even though not actually listed by the relevant standards.
> 
> Indeed, so a better patch would be to use
> 
> #if defined (_SC_NPROCESSORS_ONLN)
> 
> instead as you noted, so let's do that.

 This is what I have committed then, thank you for your review.

  Maciej
---
 gcc/ada/adaint.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Index: gcc/gcc/ada/adaint.c
===================================================================
--- gcc.orig/gcc/ada/adaint.c
+++ gcc/gcc/ada/adaint.c
@@ -2483,9 +2483,7 @@ __gnat_number_of_cpus (void)
 {
   int cores = 1;
 
-#if defined (__linux__) || defined (__sun__) || defined (_AIX) \
-  || defined (__APPLE__) || defined (__FreeBSD__) || defined (__OpenBSD__) \
-  || defined (__DragonFly__) || defined (__NetBSD__)
+#ifdef _SC_NPROCESSORS_ONLN
   cores = (int) sysconf (_SC_NPROCESSORS_ONLN);
 
 #elif defined (__QNX__)

(VAX) cc0 anyone? (was: [PATCH 0/2] Fixes for old version NetBSD targets)

[Hans-Peter Nilsson]

On Sun, 15 Nov 2020, Maciej W. Rozycki wrote:

> Hi,
>
>  In the course of my recent VAX backend modernisation effort

Hi.  That reminds me that VAX is "still" a cc0 target.

Are you aware of anyone planning on that level of modernization?

More than a year ago, there was a major heads-up that all
remaining cc0 targets would be "retired" in the next release.

Now, I'm thinking that was just an empty threat. 0:-)

brgds, H-P
PS. not volunteering, sorry.

Re: (VAX) cc0 anyone? (was: [PATCH 0/2] Fixes for old version NetBSD targets)

[Kamil Rytarowski]

[-- Attachment #1.1: Type: text/plain, Size: 629 bytes --]

On 17.11.2020 04:49, Hans-Peter Nilsson wrote:
> On Sun, 15 Nov 2020, Maciej W. Rozycki wrote:
> 
>> Hi,
>>
>>  In the course of my recent VAX backend modernisation effort
> 
> Hi.  That reminds me that VAX is "still" a cc0 target.
> 
> Are you aware of anyone planning on that level of modernization?
> 
> More than a year ago, there was a major heads-up that all
> remaining cc0 targets would be "retired" in the next release.
> 
> Now, I'm thinking that was just an empty threat. 0:-)
> 
> brgds, H-P
> PS. not volunteering, sorry.
> 

The "VAX backend modernisation effort" means upgrading out of cc0.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]