hexagon: decouple time64 types from musl symbol redirects

[androm3da]

Hexagon was added to musl after the time64 transition and never had a 32-bit time_t ABI, so its libc exports clock_gettime (not __clock_gettime64) and has no __*time64 redirect symbols. Remove hexagon from MUSL_REDIR_TIME64_ARCHES to stop applying ~45 link_name redirects that cause undefined symbol errors at link time.

The correct 64-bit time_t/suseconds_t types and timespec padding are preserved via direct target_arch = "hexagon" conditions, and linux_time_bits64 is set separately for input_event layout.

Description

Sources

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[folkertdev]

Should we run tests for hexagon in CI? It's a tier 3 target, but one that is now used in portable_simd and stdarch, so breakage here can block progress elsewhere.

(aside: maybe it's time to upgrade it to tier 2?)

[androm3da]

Should we run tests for hexagon in CI? It's a tier 3 target, but one that is now used in portable_simd and stdarch, so breakage here can block progress elsewhere.

(aside: maybe it's time to upgrade it to tier 2?)

I am fine with those - I can make the MCP if desired.

[folkertdev]

I think that we can just add tests here for targets that we believe are useful. That is what we do on stdarch with e.g. aarch64_be which is tier 3. However, I'm not a libc maintainer so that's not my call here.

But separately at least to me it seems like hexagon is at a point where tier 2 feels right.

[tgross35]

I don't think there is anything specific about this target that couldn't apply to any newer 32-bit targets, so I'd prefer not to use target_arch = "hexagon" anywhere in source.

The issue may be due to us conflating two distinct meanings of musl32_time64: one is meant to basically be a 1:1 _REDIR_TIME64, and the other is as a shorthand for cfg(all(musl_v1_2_3, target_pointer_width = "32")). I think a way to fix this would be to introduce a new config musl_redir_time64 that means exactly the same as _REDIR_TIME64, and change musl32_time64->musl_redir_time64 in places where _REDIR_TIME64 is used in source. Which would leave musl32_time64 as the 1.2.3+32-bit meaning. Does that sound workable? Maybe also rename musl32_time64 to musl_v123_b32 or something to avoid confusion, though I don't love that name.

Also how is Hexagon configured in musl? Grepping for "hexagon" yields no results.

[tgross35]

Should we run tests for hexagon in CI? It's a tier 3 target, but one that is now used in portable_simd and stdarch, so breakage here can block progress elsewhere.

(aside: maybe it's time to upgrade it to tier 2?)

Anyone maintaining a r-l repo that tests T3 targets needs to be prepared to disable those tests when things break; please do not consider libc to be blocking anything here.

Regarding libc testing: I am not interested in adding anything beyond the current build check for T3 targets. We can't really feasibly maintain CI for anything that may or may not have active maintenance, which is what the target list is meant to indicate. If target maintainers have the need, interest, and available effort to stand behind more testing, a T2 bump is the right thing to indicate that (which I do think would be reasonable enough here).

[androm3da]

I don't think there is anything specific about this target that couldn't apply to any newer 32-bit targets, so I'd prefer not to use target_arch = "hexagon" anywhere in source.

The issue may be due to us conflating two distinct meanings of musl32_time64: one is meant to basically be a 1:1 _REDIR_TIME64, and the other is as a shorthand for cfg(all(musl_v1_2_3, target_pointer_width = "32")). I think a way to fix this would be to introduce a new config musl_redir_time64 that means exactly the same as _REDIR_TIME64, and change musl32_time64->musl_redir_time64 in places where _REDIR_TIME64 is used in source. Which would leave musl32_time64 as the 1.2.3+32-bit meaning. Does that sound workable? Maybe also rename musl32_time64 to musl_v123_b32 or something to avoid confusion, though I don't love that name.

Makes sense - updated w/this suggestion.

Also how is Hexagon configured in musl? Grepping for "hexagon" yields no results.

Yeah - https://github.com/quic/musl/tree/bcain/to-upstream is our fork. We'll keep working on upstreaming that.

[androm3da]

I think I am encountering rust-lang/rust#154818 causing the CI failure in CI / Test tier1 (i686-unknown-linux-gnu)

[tgross35]

Thank you! LGTM assuming CI passes, I merged a toolchain pin.

View changes since this review

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[androm3da]

Thanks for your help @tgross35

Since the regression I introduced w/the previous libc tag is causing failures, I'd like this fix promoted to rust/.

Of course, hexagon-unknown-linux-musl is a tier 3 target so there's no urgency. But I'm wondering what the roles are - can I / should I request a new libc tag, or just wait for the natural release cadence? And once a tag exists, is it permitted/appropriate for me to create a PR against rust-lang/rust to update the libstd dependencies to use the new libc?

[tgross35]

Totally fine to poke me on a release, I'm planning to do one ~tomorrow (I'll ping you once it's out). Anybody can do the r-l/rust update, usually I don't but am happy to review :)

[tgross35]

Just released this as 0.2.185, feel free to submit a PR for rustc https://github.com/rust-lang/libc/releases/tag/0.2.185.

[folkertdev]

rust-lang/rust#155332

[androm3da]

rust-lang/rust#155332

Thanks @folkertdev - sorry for not getting to it sooner