Add initial support for hppa-unknown-linux-gnu

[hdeller]

Add libc-files to allow rust to be used on the hppa/parisc platform.

Signed-off-by: Helge Deller deller@gmx.de

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

Please see the contribution instructions for more information.

[JohnTitor]

Is there an opening request to add hppa-unknown-linux-gnu as an official target? I'd like to accept if the target is accepted on rust-lang/rust because official targets have explicit maintainers, e.g. https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/fuchsia.md#target-maintainers, and we can know if a target is still active or not, i.e. when rust-lang/rust drops the support we could follow that. This helps our maintenance work.

[hdeller]

Hi @JohnTitor,
No, I haven't yet opened an request to add hppa-unknown-linux-gnu as an official target, since it's somewhat a chicken-and-egg problem.
Similar to pull request #2414 (which is from @glaubitz for m68k), I helped Adrian @glaubitz to fill in the pieces for hppa (this pull request). Both arches are planned to use the Libgccjit codegen (rust-lang/rust#87260) but to be able to continue on this we need the libc merged first.
It would be really helpful if you could merge this pull request.
Thanks, Helge

[glaubitz]

On Dec 12, 2022, at 7:13 PM, Helge Deller ***@***.***> wrote:Similar to pull request #2414 (which is from @glaubitz for m68k), I helped Adrian @glaubitz to fill in the pieces for hppa (this pull request). Both arches are planned to use the Libgccjit codegen (rust-lang/rust#87260) but to be able to continue on this we need the libc merged first.That’s not quite correct. m68k does actually have a LLVM backend and if my memory serves right, the Rust compiler part was merged first and then came the libc part.

[JohnTitor]

I mean, you don't have to actually add the target to rust-lang/rust, but I'd like to see that you submit a PR and a reviewer approves that addition.

[glaubitz]

On Dec 14, 2022, at 11:47 AM, Yuki Okushi ***@***.***> wrote:  I mean, you don't have to actually add the target to rust-lang/rust, but I'd like to see that you submit a PR and a reviewer approves that addition.

Correct me if I’m wrong, but with the Rust frontend now being merged into gcc master, I think isn’t necessarily a hard requirement any more, is it?

[JohnTitor]

Repeating #3032 (comment), but I'm not talking about technical requirements but maintenance burden. It'd be quite hard to maintain the crate if we accepted all the targets unconditionally (actually, we have received some requests about an unofficial target and decisions were very difficult to make about who to contact, how much use this target is getting, and whether it is safe to delete it, etc.).

[glaubitz]

On Dec 14, 2022, at 12:41 PM, Yuki Okushi ***@***.***> wrote: Repeating #3032 (comment), but I'm not talking about technical requirements but maintenance burden. It'd be quite hard to maintain the crate if we accepted all the targets unconditionally (actually, we have received some requests about an unofficial target and decisions were very difficult to make about who to contact, how much use this target is getting, and whether it is safe to delete it, etc.). What about adding a MAINTAINERS file?I’d be happy to take responsibility of m68k, powerpc, ppc64be and sparc64, for example.Helge would take responsibility for hppa.

[hdeller]

Yes, I'd be happy to maintain the hppa part.

[JohnTitor]

It still adds maintenance burden to the libc maintainers to make the list up-to-date. I'm also not sure why forked libc repo doesn't work while they use a custom target, so I'd still prefer following the rustc's target support.

[glaubitz]

It still adds maintenance burden to the libc maintainers to make the list up-to-date. I'm also not sure why forked libc repo doesn't work while they use a custom target, so I'd still prefer following the rustc's target support.

Because Linux distributions don't use forked packages. There is one version of every package.

If individual Rust crates refuse to add support for architectures that are supported by other Rust compilers, I'm not sure what the point of additional Rust compilers with broader architecture support is.

I also don't think there is really a huge burden of maintenance when adding new architectures to the libc crate. It's not that the SysV ABI of a given architecture is a moving target.

[JohnTitor]

I didn't think of Linux distribution packages, that's fair enough. Could you give me some time to think about adding a new target? I believe we definitely establish a policy for that.

[glaubitz]

We can postpone this until support for hppa has been added through the rustc_codegen_gcc backend since then support for this architecture will also be part of the official Rust compiler.

[workingjubilee]

There has been an intention to establish a policy for "candidate targets" for some time. These would be essentially a way of defining targets that we (as in rustc) does not have support for, nor even expect to add support for soon, but would consider adding, without actually defining them in-code. It would be a way of essentially, openly discussing, "if we could add this target, roughly what would it look like?" so that other Rust compilers could come to agreement with us, so that software would be portable, and so that future possible targets could inform design decisions. This wouldn't necessarily e.g. handle cross-compiler ABI issues, since repr(Rust) remains unspecified for now.

This policy hasn't been formalized yet, it's still something people are kicking around, but it would likely alleviate the pressure here.

[bors]

☔ The latest upstream changes (presumably #3525) made this pull request unmergeable. Please resolve the merge conflicts.

[antoyo]

What's the status of this?
What is blocking this PR from being merged?

[hdeller]

Oops... I rebased that pull request and updated the branch, but hppa-devel3 (the updated patch) is again available at
https://github.com/hdeller/libc/tree/hppa-devel3
Can this branch be included here in this pull request again?

[hdeller]

Shall I open a new pull request, or what is the best way?

[hdeller]

New pull request is here:
#3539