> Date: Thu, 09 Jul 2026 14:40:18 +0200
> From: Kirill A. Korinsky <kirill@korins.ky>
> 
> On Thu, 09 Jul 2026 14:05:59 +0200,
> Mark Kettenis <mark.kettenis@xs4all.nl> 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.