Re: [PATCH] Remove v850 from linux/elf-em.h

[David Daney]

On 03/16/2016 12:11 AM, Rob Landley wrote:
> On 03/15/2016 06:22 PM, David Daney wrote:
> > On 03/15/2016 02:10 PM, Rob Landley wrote:
> > > From: Rob Landley <rob@xxxxxxxxxxx>
> > >
> > > The v850 port was removed by commits f606ddf42fd4 and 07a887d399b8 in
> > > 2008.
> > > These #defines are not used in the current kernel.
> > >
> > > Signed-off-by: Rob Landley <rob@xxxxxxxxxxx>
> > > ---
> > >    include/uapi/linux/elf-em.h |    3 ---
> > >    1 file changed, 3 deletions(-)
> > >
> > > diff --git a/include/uapi/linux/elf-em.h b/include/uapi/linux/elf-em.h
> > > index b56dfcf..c3fdfe7 100644
> > > --- a/include/uapi/linux/elf-em.h
> > > +++ b/include/uapi/linux/elf-em.h
> > > @@ -30,7 +30,6 @@
> > >    #define EM_X86_64    62    /* AMD x86-64 */
> > >    #define EM_S390        22    /* IBM S/390 */
> > >    #define EM_CRIS        76    /* Axis Communications 32-bit embedded
> > > processor */
> > > -#define EM_V850        87    /* NEC v850 */
> >
> > Can you do this to userspace visible files?
>
> Commit 6f6f467eaaa0 did and nobody seemed to mind?

Evidence of prior art doesn't prove correctness.

> > I thought only additions and obvious corrections were allowed.  Removing
> > symbols could cause build breakage for something.
>
> There's a /usr/include/elf.h in glibc with 3 times as many EM_BLAH
> symbols as this one defines. Something that cares about identifying
> architectures Linux doesn't actually support would presumably use that
> header instead of this one.
>
> This is the only architecture included in this file that isn't currently
> supported by Linux (except the mips symbols with the comment about them
> not being used, which have been there since the first version of the file).
>
> I found this while auditing toybox's "file" command. (We just copied the
> constant values into our own table, but when making the table I was
> checking which values the actual Linux ELF loaders in the various arch
> directories would bind to.)

The symbols are not hurting anything, they also do not have incorrect 
values.  They are however visible to userspace.  I am not going to 
comment on it any more, but there is a higher burden for removing things 
that might break userspace programs, than there is for removing code 
guaranteed not to be userspace visible.

I think the admonition about not breaking userspace has to be considered 
in this case.

It could be that there is nothing that uses these symbols, but we have 
no way of knowing for sure.  So, unless there is a compelling reason to 
do this, the lowest risk strategy is to do nothing.


David Daney