Re: ld.so/sparc64: fix UA64 relocation mask selection and byte order
Mark Kettenis <[email protected]>
| Newsgroups | gmane.os.openbsd.tech |
|---|---|
| Message-ID | <[email protected]> |
> Date: Thu, 09 Jul 2026 14:40:18 +0200 > From: Kirill A. Korinsky <[email protected]> > > On Thu, 09 Jul 2026 14:05:59 +0200, > Mark Kettenis <[email protected]> wrote: > > > > However, it worries me that you actually hit the RELOC_UNALIGNED() > > cases. To me that indicates that something isn't quite right in the > > generated code. > > > > I think the missed part that lld keeps R_SPARC_UA64 for the final relocation > offset is aligned. > > Here that tb@ shared with me from broken libssl: > > 0000000000363848 0000008f00000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha512 + 0 > 0000000000363868 0000008f00000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha512 + 0 > 0000000000363948 0000008f00000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha512 + 0 > 00000000003639a8 0000008f00000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha512 + 0 > 0000000000363888 0000009000000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha384 + 0 > 00000000003638a8 0000009000000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha384 + 0 > 0000000000363928 0000009000000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha384 + 0 > 0000000000363988 0000009000000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha384 + 0 > 00000000003638c8 0000009100000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha256 + 0 > 00000000003638e8 0000009100000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha256 + 0 > 0000000000363908 0000009100000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha256 + 0 > 0000000000363968 0000009100000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha256 + 0 > 00000000003639c8 0000009200000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha224 + 0 > 00000000003639e8 0000009200000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha224 + 0 > 0000000000363a08 0000009300000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha1 + 0 > 0000000000363a28 0000009300000036 R_SPARC_UA64 0000000000000000 _libre_EVP_sha1 + 0 > 00000000002609c0 0000009000000015 R_SPARC_JMP_SLOT 0000000000000000 _libre_EVP_sha384 + 0 > 00000000002609e0 0000009100000015 R_SPARC_JMP_SLOT 0000000000000000 _libre_EVP_sha256 + 0 > 0000000000260a00 0000009300000015 R_SPARC_JMP_SLOT 0000000000000000 _libre_EVP_sha1 + 0 > > everything is quite alligned, but it has R_SPARC_UA64 > > I can try to make bfd-like behaviour to replace R_SPARC_UA64 to R_SPARC_64 > when it is the alligned offsets at the end. > > But do we really need it? I think we do. These "unaligned" relocations might not work in a multi-threaded context as threads may observed a partially updated state.