[RFC][PATCH] Remove binutils support for Nios II target

[Jan Beulich]

On 25.11.2024 22:12, Sandra Loosemore wrote:
> The attached patch removes binutils support for the Nios II target, 
> which has been EOL'ed by the vendor.  I've already pushed the patch to 
> remove support from GCC:
> 
> https://gcc.gnu.org/pipermail/gcc-cvs/2024-November/413482.html
> 
> I've also got a separate gdb patch I'm about to post and I'd like to get 
> them both in at the same time.
> 
> I'm the binutils maintainer as well so I don't need review of this patch 
> to push it, but I have a couple questions before I push the button....
> 
> (1) I've left the readelf support in place since this is supposed to be 
> a utility that can read the headers in any ELF file instead of a 
> target-specific thing.  Is that the Right Thing to do?

Yes and ...

>  It's basically 
> just header file definitions for EM_ALTERA_NIOS2 and its associated 
> RELOC numbers, neither of which is ever going to change.  That 
> information is also present in the generic elf.h distributed with glibc 
> and newlib, along with similar information for some other obsolete 
> targets, so I guess the accepted practice is to leave it in place 
> everywhere?

... yes, afaict.

> (2) I'm confused about what's going on with ChangeLogs in binutils.  It 
> seems like some commits include ChangeLogs in the commit message and 
> others don't, but nothing is propagating the logs in commit messages to 
> actual ChangeLog files, which still exist but are not marked as 
> obsolete, and there's nothing on the binutils web page about patch 
> formatting.  Should I add a ChangeLog to the commit message?

As per a couple of years ago ChangeLog entries aren't required anymore,
so it really is up to you. Originally it may have been meant to work
like for gcc, where ChangeLog entries would be propagated from the
commit messages, yet that doesn't appear to have been made work.
(Personally I'm in favor of proper verbal descriptions of patches
anyway, as that often helps understand the "why", whereas the
mechanical "what" in the ChangeLogs are something one typically could
reconstruct quite easily from the actual code changes.)

A comment on the patch itself: Very lightly going over it, I notice a
seemingly stray change to */Makefile.in (first hunk each).

Jan