port-vax/59326: pointer to global function in same object file points PLT entry

[rokuyama.rk%gmail.com@localhost]

>Number:         59326
>Category:       port-vax
>Synopsis:       pointer to global function in same object file points PLT entry
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-vax-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 19 05:25:00 +0000 2025
>Originator:     Rin Okuyama
>Release:        10.99.12 (and netbsd-9 at least)
>Organization:
Internet Initiative Japan Inc.
>Environment:
NetBSD  10.99.12 NetBSD 10.99.12 (GENERIC) #1: Sun Apr 13 19:38:40 JST 2025  rin@sakaizumii.local:/home/rin/src/sys/arch/vax/compile/obj.vax-vax/GENERIC vax
>Description:
Many rump-based ATF cases do not work on vax. For example,
if_bridge:bridge_ipv4 fails as:

```
tc-so:Executing command [ /sbin/brconfig bridge0 add shmif0 ]
tc-se:Fail: incorrect exit status: 1, expected: 0
tc-se:stdout:
tc-se:
tc-se:stderr:
tc-se:brconfig: add shmif0: Invalid argument
tc-se:
```

This EINVAL comes from if_bridge.c:bridge_ioctl_add():

```
	if (ifs->_if_input != ether_input) {
		error = EINVAL;
		goto out;
	}
```

This is strange since _if_input for shmif(4) should be
initialized to ether_input() in if_ethersubr.c::ether_ifattach():

```
	ifp->_if_input = ether_input;
```

Inserting debug printf's for ether_input value, I observed:

```
[   4.7600050] ether_ifattach: ether_input: 0x7f045918
[   8.1500050] bridge_ioctl_add: ether_input: 0x7f0b67f0
```

(Here, I used RUMP_STDOUT environment variable to obtain this log.)

This is not a recent regression; similar ATF failures also happen
at least for netbsd-9.

This inconsistency is because pointers for ether_ifattach point
(1) PLT entry for ether_ifattach(), and (2) GOT entry for
bridge_ioctl_add(), respectively.

This, of course, cannot be worked around even by LD_BIND_NOW.
>How-To-Repeat:
As a minimal reproducer, callee() pointers behave similarly for
callee.c and caller.c below:

callee.c:
```
#include <stdio.h>

void
callee(void)
{
}

static void
print_callee(void)
{

	printf("%s: %p\n", callee);
}
```

caller.c:
```
#include <stdio.h>

void callee(void);

void
caller(void)
{

	callee();
	printf("%s: %p\n", callee);
}
```

Then, I got:

```
% cc -fPIC -c callee.c
% readelf -a callee.o
...
Relocation section '.rela.text' at offset 0x1a0 contains 3 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
...
0000000f  0000090d R_VAX_PLT32       00000000   callee + 0
...
% readelf -a callee.o
```

and

```
% cc -fPIC -c caller.c
% readelf -a caller.o
...
Relocation section '.rela.text' at offset 0x180 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
...
00000008  0000090d R_VAX_PLT32       00000000   callee + 0
0000000e  00000907 R_VAX_GOT32       00000000   callee + 0
...
```

You can see function pointer local to callee.o as well as function
call for caller.o point PLT entry, whereas function pointer in
callee.o points GOT entry.

For amd64, e.g., function pointer in callee.o points GOT entry,
not PLT, in a similar manner to caller.o.
>Fix:
For upstream, this behavior seems to be introduced by this commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7b6021f1972

With this patch:
https://gist.github.com/rokuyama/181d7208bd099899a24cb6a70a809616

function pointers always point to GOT entries, even if functions are
local to object files.

With the patch applied, I've confirmed:

(1) full distribution (with MKX11) can be cross-built,
(2) **most** rump-based ATF cases become working fine,
(3) no new regression for full ATF runs, and
(4) perl-5.38.2 can be built natively.