All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@linux-mips.org: linux
Date: Fri, 22 Jul 2005 16:16:02 +0200	[thread overview]
Message-ID: <20050722141602.GF1692@hattusa.textio> (raw)
In-Reply-To: <20050722130655.GD3803@linux-mips.org>

Ralf Baechle wrote:
> On Fri, Jul 22, 2005 at 02:10:30PM +0200, Thiemo Seufer wrote:
> > Date:	Fri, 22 Jul 2005 14:10:30 +0200
> > To:	Ralf Baechle <ralf@linux-mips.org>
> > Cc:	linux-mips@linux-mips.org
> > Subject: Re: CVS Update@linux-mips.org: linux
> > Content-Type: text/plain; charset=us-ascii
> > From:	Thiemo Seufer <ths@networkno.de>
> > 
> > Ralf Baechle wrote:
> > > On Thu, Jul 21, 2005 at 04:33:53PM +0100, ths@linux-mips.org wrote:
> > > 
> > > > Modified files:
> > > > 	arch/mips/kernel: binfmt_elfo32.c 
> > > > 	include/asm-mips: elf.h 
> > > > 
> > > > Log message:
> > > > 	Fix ELF defines: EF_* is a field, E_* a distinct flag therein.
> > > 
> > > Remarkably bad idea after the old definitions are already being used since
> > > over a decade.
> > 
> > Well, kernel headers are less widely used than others, and everywhere
> > else it is E_*. Since
> >  - kernel headers in general aren't meant as an interface for userland,
> >  - the definition is inconsistent to the userland one,
> 
> Glibc is the only thing elf.h that defines the E_* names at all and
> explicitly says "don't use".

It looks like things are worse than just different naming:

Glibc prefers:
#define EF_MIPS_ARCH_1      0x00000000  /* -mips1 code.  */
#define EF_MIPS_ARCH_2      0x10000000  /* -mips2 code.  */
#define EF_MIPS_ARCH_3      0x20000000  /* -mips3 code.  */
#define EF_MIPS_ARCH_4      0x30000000  /* -mips4 code.  */
#define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
#define EF_MIPS_ARCH_32     0x60000000  /* MIPS32 code.  */
#define EF_MIPS_ARCH_64     0x70000000  /* MIPS64 code.  */

and knows also but depreciates:
#define E_MIPS_ARCH_1     0x00000000    /* -mips1 code.  */
#define E_MIPS_ARCH_2     0x10000000    /* -mips2 code.  */
#define E_MIPS_ARCH_3     0x20000000    /* -mips3 code.  */
#define E_MIPS_ARCH_4     0x30000000    /* -mips4 code.  */
#define E_MIPS_ARCH_5     0x40000000    /* -mips5 code.  */
#define E_MIPS_ARCH_32    0x60000000    /* MIPS32 code.  */
#define E_MIPS_ARCH_64    0x70000000    /* MIPS64 code.  */

Gcc/binutils actually create:
#define E_MIPS_ARCH_1           0x00000000
#define E_MIPS_ARCH_2           0x10000000
#define E_MIPS_ARCH_3           0x20000000
#define E_MIPS_ARCH_4           0x30000000
#define E_MIPS_ARCH_5           0x40000000
#define E_MIPS_ARCH_32          0x50000000
#define E_MIPS_ARCH_64          0x60000000
#define E_MIPS_ARCH_32R2        0x70000000
#define E_MIPS_ARCH_64R2        0x80000000

The kernel has (had):
#define EF_MIPS_ARCH_1	0x00000000      /* -mips1 code.  */
#define EF_MIPS_ARCH_2	0x10000000      /* -mips2 code.  */
#define EF_MIPS_ARCH_3	0x20000000      /* -mips3 code.  */
#define EF_MIPS_ARCH_4	0x30000000      /* -mips4 code.  */
#define EF_MIPS_ARCH_5	0x40000000      /* -mips5 code.  */
#define EF_MIPS_ARCH_32	0x50000000      /* MIPS32 code.  */
#define EF_MIPS_ARCH_64	0x60000000      /* MIPS64 code.  */
#define EF_MIPS_ARCH_32R2     0x70000000	/* MIPS32 R2 code.  */
#define EF_MIPS_ARCH_64R2     0x80000000	/* MIPS64 R2 code.  */

so glibc misinterprets E(F)_MIPS_ARCH_{32,64} as used by the toolchain.

> >  - the in-kernel use seems to be limited to the ELF binary object
> >    loader and probably third party modules loaders
> > I found moving to a consistent definition to be more useful than
> > keeping the old inconsistent one.
> 
> I think you're confusing binutils's internal definitions with the use
> everywhere else.
> 
> Mind pulling that patch?

I would prefer to have the same consistent set of names for all users.

Maciej made the point that the EF_ prefix is common for ELF header flag
defines, this suggests to standardize on the defines the kernels had
previously. This might break glibc's ld.so for third party toolchains
which followed the glibc definitions (if they actually exist).

Comments?


Thiemo

  parent reply	other threads:[~2005-07-22 14:14 UTC|newest]

Thread overview: 107+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050721153359Z8225218-3678+3745@linux-mips.org>
2005-07-22  4:30 ` CVS Update@linux-mips.org: linux Ralf Baechle
2005-07-22  9:04   ` Going over 512M of memory Alex Gonzalez
2005-07-22 13:14     ` Ralf Baechle
2005-07-22 13:32       ` Alex Gonzalez
2005-07-25  7:43         ` Rojhalat Ibrahim
2005-07-25  8:54           ` Alex Gonzalez
2005-07-25  9:23             ` Rojhalat Ibrahim
2005-07-22  9:10   ` Realtime preemption patches Alex Gonzalez
2005-07-22 12:10   ` CVS Update@linux-mips.org: linux Thiemo Seufer
2005-07-22 13:06     ` Ralf Baechle
2005-07-22 13:24       ` Maciej W. Rozycki
2005-07-22 14:00         ` Ralf Baechle
2005-07-22 14:18           ` Thiemo Seufer
2005-07-26 11:12           ` Maciej W. Rozycki
2005-07-22 14:16       ` Thiemo Seufer [this message]
     [not found] <20050921213950Z8225559-3678+10018@linux-mips.org>
2005-09-22  9:28 ` Matej Kupljen
     [not found] <20050920002016Z8225531-3678+9789@linux-mips.org>
2005-09-20  8:19 ` Jerry
2005-09-20 14:53   ` Pete Popov
     [not found] <20050902095417Z8224772-3678+8160@linux-mips.org>
2005-09-02 11:35 ` Maciej W. Rozycki
2005-09-02 12:01   ` Thiemo Seufer
2005-09-02 13:30     ` Maciej W. Rozycki
     [not found] <20050901085634Z8225385-3678+8053@linux-mips.org>
2005-09-01 11:18 ` Ralf Baechle
2005-09-01 11:31   ` Ralf Baechle
     [not found] <20050820142723Z8225252-3678+7060@linux-mips.org>
2005-08-22  9:18 ` Maciej W. Rozycki
2005-08-22 10:26   ` Ralf Baechle
2005-08-22 11:49     ` Maciej W. Rozycki
     [not found] <20050727214818Z8225782-3678+4592@linux-mips.org>
2005-07-28 10:19 ` Maciej W. Rozycki
     [not found] <20050725213607Z8225534-3678+4335@linux-mips.org>
     [not found] ` <57480.194.171.252.10 0.1122478386.squirrel@mail.kpsws.com>
2005-07-27 15:33 ` Niels Sterrenburg
2005-07-27 15:37   ` Geert Uytterhoeven
2005-07-27 16:37     ` Maciej W. Rozycki
2005-07-27 17:24   ` Ralf Baechle
2005-07-27 18:03     ` Maciej W. Rozycki
2005-07-27 19:28       ` Ralf Baechle
2005-07-28  7:36         ` Geert Uytterhoeven
2005-07-28 10:13           ` Maciej W. Rozycki
2005-07-28 13:46             ` Ralf Baechle
2005-07-28 11:23           ` Niels Sterrenburg
     [not found] <20050721153639Z8225221-3678+3748@linux-mips.org>
2005-07-21 21:53 ` Ralf Baechle
     [not found] <20050714174806Z8226711-3678+3079@linux-mips.org>
2005-07-15 15:16 ` Yoichi Yuasa
2005-07-15 18:07   ` Ralf Baechle
2005-07-15 23:23   ` Pete Popov
2005-07-15 23:23     ` Pete Popov
     [not found] <20050714001711Z8226701-3678+2977@linux-mips.org>
2005-07-14 15:35 ` Maciej W. Rozycki
2005-07-14 15:51   ` Pete Popov
2005-07-14 15:59     ` Maciej W. Rozycki
2005-07-14 16:01       ` Pete Popov
     [not found] <20050712145438Z8226641-3678+2759@linux-mips.org>
2005-07-12 15:30 ` Maciej W. Rozycki
     [not found] <20050711170613Z8226486-3678+2546@linux-mips.org>
2005-07-11 17:31 ` Ralf Baechle
2005-07-11 17:44   ` Maciej W. Rozycki
2005-07-11 17:53     ` Ralf Baechle
2005-07-11 18:05       ` Maciej W. Rozycki
2005-07-11 19:25         ` Thiemo Seufer
2005-07-12 11:16           ` Maciej W. Rozycki
     [not found] <20050711083532Z8226446-3678+2437@linux-mips.org>
2005-07-11  8:45 ` Ralf Baechle
     [not found] <20050708091711Z8226352-3678+1954@linux-mips.org>
2005-07-08 12:02 ` Ralf Baechle
2005-07-08 12:12   ` Maciej W. Rozycki
2005-07-08 13:43     ` Richard Sandiford
2005-07-08 13:55     ` Ralf Baechle
     [not found] <20050707091937Z8226163-3678+1737@linux-mips.org>
2005-07-07 11:32 ` Maciej W. Rozycki
2005-07-07 12:12   ` Thiemo Seufer
2005-07-07 12:19     ` Maciej W. Rozycki
2005-07-07 12:22       ` Thiemo Seufer
2005-07-07 13:01         ` Maciej W. Rozycki
2005-07-07 13:51           ` Thiemo Seufer
2005-07-07 16:29           ` Ralf Baechle DL5RB
2005-07-07 16:42             ` Maciej W. Rozycki
2005-07-08 13:42             ` Richard Sandiford
2005-07-08 15:05               ` Maciej W. Rozycki
2005-07-08 15:39                 ` Richard Sandiford
2005-07-08 15:59                   ` Maciej W. Rozycki
     [not found] <20050618135450Z8225248-1340+9141@linux-mips.org>
2005-06-20 10:27 ` Maciej W. Rozycki
     [not found] <20050605035727Z8225003-1340+8177@linux-mips.org>
2005-06-06 12:16 ` Ralf Baechle
     [not found] <20050603022113Z8226140-1340+8064@linux-mips.org>
2005-06-03  9:22 ` Ralf Baechle
2005-06-03 10:21   ` Thiemo Seufer
2005-06-03 10:55     ` Ralf Baechle
2005-06-03 11:12     ` Geert Uytterhoeven
2005-06-03 11:30       ` Ralf Baechle
2005-06-03 11:37         ` Geert Uytterhoeven
     [not found] <20050506143118Z8225421-1340+6642@linux-mips.org>
2005-05-06 14:51 ` Maciej W. Rozycki
2005-05-06 18:41   ` Maciej W. Rozycki
     [not found] <20050412140045Z8224988-1340+5602@linux-mips.org>
2005-04-12 16:57 ` Christoph Hellwig
2005-04-12 17:48   ` Thiemo Seufer
     [not found] <20050401175340Z8226142-1340+5040@linux-mips.org>
2005-04-02 10:11 ` Thiemo Seufer
2005-04-04 11:26   ` Maciej W. Rozycki
     [not found] <20050304151343Z8225933-1340+3959@linux-mips.org>
2005-03-16 18:51 ` Maciej W. Rozycki
     [not found] <20050225133831Z8225462-1340+3675@linux-mips.org>
2005-02-25 16:50 ` Maciej W. Rozycki
     [not found] <20050225131124Z8225457-1340+3673@linux-mips.org>
2005-02-25 16:48 ` Maciej W. Rozycki
     [not found] <20050214035304Z8225242-1340+3175@linux-mips.org>
2005-02-14 15:34 ` Ralf Baechle
2005-02-14 15:41   ` sjhill
2005-02-14 16:06   ` Maciej W. Rozycki
2005-02-14 18:34     ` Ralf Baechle
     [not found] <20050213213130Z8225210-1340+3164@linux-mips.org>
2005-02-13 21:33 ` Maciej W. Rozycki
     [not found] <20050115013112Z8225557-1340+1316@linux-mips.org>
2005-01-19  4:42 ` Yoichi Yuasa
2005-01-19  5:04   ` Maciej W. Rozycki
2005-01-19  5:31     ` Yoichi Yuasa
2005-01-19  5:35       ` Maciej W. Rozycki
2005-01-19  6:21         ` Yoichi Yuasa
2005-03-07 16:44           ` Yoichi Yuasa
2005-03-17 15:47             ` Yoichi Yuasa
2005-03-20 22:14               ` Ralf Baechle
     [not found] <20050109193411Z8225245-1340+894@linux-mips.org>
2005-01-09 20:55 ` Geert Uytterhoeven
2005-01-09 21:15   ` Ralf Baechle
     [not found] <20050108180025Z8225397-1340+834@linux-mips.org>
2005-01-08 20:25 ` Ilya A. Volynets-Evenbakh
2005-01-08 22:07   ` Ralf Baechle
     [not found] <20050107191947Z8225432-1341+49@linux-mips.org>
2005-01-07 20:43 ` Ilya A. Volynets-Evenbakh
2005-01-08  0:56   ` Thiemo Seufer
     [not found] <20041228080623Z8224908-1340+368@linux-mips.org>
2005-01-01 13:40 ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050722141602.GF1692@hattusa.textio \
    --to=ths@networkno.de \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.