Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: sysbuild of netbsd-10 from netbsd-10 fails after upgrade of itself
On Tue, 7 Oct 2025, Greg A. Woods wrote:
Those beNNXXc() functions should be inlined, I think -- they are defined
in <sys/endian.h> via a set of macros for any compiler since gcc-2.95.
Those beNNXXc() functions are tested twice, actually. First, during the
creation of `nbtool_config.h' by `tools/compat/configure'. The second, when
sha2.c is compiled.
Only in the first case is <sys/endian.h> used, and here, the beNNXXc() are
not seen and `tools/include/compat/nbtool_config.h' ends up with:
```
#define HAVE_DECL_BE64DEC 0
#define HAVE_DECL_BE64ENC 0
```
etc., because `configure' compiles the test progs. as follows:
```
configure: failed program was:
| /* confdefs.h */
[...]
| #define _POSIX_SOURCE 1
| #define _POSIX_C_SOURCE 200112L
| #define _XOPEN_SOURCE 600
[...]
| /* end confdefs.h. */
| #include <sys/endian.h>
|
| int
| main ()
| {
| #ifndef be64enc
| #ifdef __cplusplus
| (void) be64enc;
| #else
| (void) be64enc;
| #endif
| #endif
|
| ;
| return 0;
| }
configure:5981: result: no
```
Defining `_POSIX_SOURCE 1' undefs `_NETBSD_SOURCE' in <sys/featuretest.h>
When compiling sha2.c, <sys/endian.h> isn't used at all. What's used are the
beNNXXc() definitions in `tools/compat/compat_defs.h':
sha2.c -> nbtool_compat.h -> compat_def.h -> beNNXXc()
because `nbtool_compat.h' gets pulled in, and now has (as expected):
```
/* Define to 1 if you have the declaration of `be64dec', and to 0 if you
don't. */
#define HAVE_DECL_BE64DEC 0
/* Define to 1 if you have the declaration of `be64enc', and to 0 if you
don't. */
#define HAVE_DECL_BE64ENC 0
```
as a result of the `./configure' tests.
However they do not get inlined:
$ nm /home/sysbuild/i386/obj/home/sysbuild/src/tools/compat/sha2.lo
00000340 r K256
00000080 r K512
000002d5 t SHA224_256_Final
00000914 T SHA224_Final
00000834 T SHA224_Init
000008f8 T SHA224_Transform
000008d5 T SHA224_Update
0000081f T SHA256_Final
00000000 T SHA256_Init
000000a1 T SHA256_Transform
0000056e T SHA256_Update
000017ef T SHA384_Final
000016bd T SHA384_Init
000017d3 T SHA384_Transform
000017b0 T SHA384_Update
00001630 T SHA512_Final
00000929 T SHA512_Init
00000fec t SHA512_Last
00000a1c T SHA512_Transform
000012ad T SHA512_Update
U be32dec
U be32enc
U be64dec
U be64enc
00000320 r sha224_initial_hash_value
00000300 r sha256_initial_hash_value
00000040 r sha384_initial_hash_value
00000000 r sha512_initial_hash_value
They should get inlined. Well, at least some of them should: the compiler can
inline the code depending on optimization flags and code usage, it looks like:
```
qemu$ nm /tmp/obj/home/rvp/src/netbsd-10/tools/compat/sha2.lo
0000000000000340 r K256
0000000000000080 r K512
00000000000002f5 t SHA224_256_Final
0000000000000922 T SHA224_Final
0000000000000839 T SHA224_Init
0000000000000917 T SHA224_Transform
000000000000090c T SHA224_Update
0000000000000829 T SHA256_Final
0000000000000007 T SHA256_Init
00000000000000da T SHA256_Transform
0000000000000603 T SHA256_Update
0000000000001304 T SHA384_Final
000000000000121e T SHA384_Init
00000000000012f9 T SHA384_Transform
00000000000012ee T SHA384_Update
0000000000001180 T SHA512_Final
0000000000000932 T SHA512_Init
0000000000000c44 t SHA512_Last
0000000000000a02 T SHA512_Transform
0000000000000eb5 T SHA512_Update
0000000000000000 t be64enc <---
U memcpy
0000000000000320 r sha224_initial_hash_value
0000000000000300 r sha256_initial_hash_value
0000000000000040 r sha384_initial_hash_value
0000000000000000 r sha512_initial_hash_value
qemu$
```
Note that on amd64, only `be64enc' is visible because only that func. is used
twice in the code. All of the others are used only once, so, presumably, the
compiler has inlined the code of those funcs. rather than inlining those
functions themselves.
So, this looks like some local issue. Does `nbtool_config.h' have
```
#define HAVE_DECL_BE64DEC 1
```
or something?
HTH,
-RVP
Home |
Main Index |
Thread Index |
Old Index