From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Clifton To: cgd@sibyte.com Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: RFA: Recording MIPS ABI selection in binaries Date: Tue, 08 Aug 2000 17:30:00 -0000 Message-id: <200008090030.RAA19784@elmo.cygnus.com> X-SW-Source: 2000-08/msg00164.html Hi Chris, : as far as i'm concerned, there could have been better use of the : existing bits for ABIs (by enumeration, rather than flags) Indeed, but as you say we are stuck with legacy code which we need to carry on supporting, so I doubt if these flags will change any time soon. : Personally I'd like to see the existing flags rationalized to the : extent that they can be, and improved from there, rather than : perpetuate the existing morass and even make it worse by introducing a : mechanism that's not particularly scalable, The scheme is scalable. In fact it is more scalable than the existing scheme of using bits in the file header. The sections can have arbitrary names which can be used to encode pretty much anything. : and is redundant with the aim of some existing mechanisms. Well it would be redundant if the current bits were reorganised, but I really doubt if that is going to happen. Cheers Nick >From cgd@sibyte.com Tue Aug 08 18:19:00 2000 From: cgd@sibyte.com (Chris G. Demetriou) To: Nick Clifton Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: RFA: Recording MIPS ABI selection in binaries Date: Tue, 08 Aug 2000 18:19:00 -0000 Message-id: <5tittb2pv3.fsf@highland.sibyte.com> References: <200008090030.RAA19784@elmo.cygnus.com> X-SW-Source: 2000-08/msg00165.html Content-length: 1954 Nick Clifton writes: > : as far as i'm concerned, there could have been better use of the > : existing bits for ABIs (by enumeration, rather than flags) > > Indeed, but as you say we are stuck with legacy code which we need to > carry on supporting, so I doubt if these flags will change any time > soon. yes, i guess one of my questions was, how many of these flags are defined by some pseudo-standard body, and how many were the invention of the gnu tools folks. and then, given that, how much trouble would be basically be to declare some period of time in which nobody would set them, and everybody would ignore them, or something, to lessen backward-compat hassles. Also, what's the specific case you're trying to solve? (you said you're talking about -mgp32... but what's the resulting ABI? it looks like existing bits can be used to expressed eabi32, eabi64, n32 o32, and o64, but not "64" (but that seems to conflict with your original statement that you need to differentiate between not using -mgp32 and using it). > : and is redundant with the aim of some existing mechanisms. > > Well it would be redundant if the current bits were reorganised, but I > really doubt if that is going to happen. certainly, nobody's going to solve the problem if every time it comes up nobody resists new additions that go further from the 'right thing.' 8-) That actually makes me think: the defined values for EF_MIPS_MACH are unused, and, really, per my previous thought, EF_MIPS_MACH is really better expressed by something like what you're currently proposing. You could deprecate its use and steal a few bits from it (looks like 4, non-contiguous), without breaking backward compatibility with the defines in the existing headers, if you are careful. Also, if the goal is to have these replace the ABI flags, detection of ABI conflicts using the new section indicators really should be added to ld (or bfd). cgd >From ac131313@cygnus.com Tue Aug 08 18:36:00 2000 From: Andrew Cagney To: "Chris G. Demetriou" Cc: Nick Clifton , gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: RFA: Recording MIPS ABI selection in binaries Date: Tue, 08 Aug 2000 18:36:00 -0000 Message-id: <3990B4BE.C2273617@cygnus.com> References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com> X-SW-Source: 2000-08/msg00166.html Content-length: 563 "Chris G. Demetriou" wrote: > That actually makes me think: > > the defined values for EF_MIPS_MACH are unused, and, really, per my > previous thought, EF_MIPS_MACH is really better expressed by something > like what you're currently proposing. You could deprecate its use and > steal a few bits from it (looks like 4, non-contiguous), without > breaking backward compatibility with the defines in the existing > headers, if you are careful. FYI, EF_MIPS_MACH is used to determine the ISA. Its fairly orthogonal to ABI related flags such as -mgp32. Andrew >From cgd@sibyte.com Tue Aug 08 18:49:00 2000 From: cgd@sibyte.com (Chris G. Demetriou) To: Andrew Cagney Cc: Nick Clifton , gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: RFA: Recording MIPS ABI selection in binaries Date: Tue, 08 Aug 2000 18:49:00 -0000 Message-id: <5thf8v2oh5.fsf@highland.sibyte.com> References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com> <3990B4BE.C2273617@cygnus.com> X-SW-Source: 2000-08/msg00167.html Content-length: 2141 Andrew Cagney writes: > "Chris G. Demetriou" wrote: > > That actually makes me think: > > > > the defined values for EF_MIPS_MACH are unused, and, really, per my > > previous thought, EF_MIPS_MACH is really better expressed by something > > like what you're currently proposing. You could deprecate its use and > > steal a few bits from it (looks like 4, non-contiguous), without > > breaking backward compatibility with the defines in the existing > > headers, if you are careful. (FYI, i think i might have deleted my "previous thought" in an edit of the message.) > FYI, EF_MIPS_MACH is used to determine the ISA. Its fairly orthogonal > to ABI related flags such as -mgp32. yes. And what purpose is there in expressing that a binary uses exactly one ISA's/CPU's type of instructions, i.e. why should it be encoded the way it is? Use of an ISA is not exclusive; you can use multiple ISAs in a single executable, with (strongly desirable) good effect. the type of mechanism for recording ABI Nick has proposed is not particularly appropriate for recording ABI, since it really has no notion of exclusivity (which as far as I can tell is appropriate for ABI). On the other hand, i realized that it's almost perfect for recording ISA. 8-) so, steal a few unused bits from that field. old tools will think the ISA's unknown, no biggie. new tools faced with old binaries might get the ABI wrong... but they'd do that anyway. and it gets the situation closer to 'right', at least. (believe me, i have a strong interest in a sane solution to this problem...) I just looked through the current set of flags in elf/mips.h. i guess i just don't understand why: * any additional ABI indication needed can't be stuffed into one of the existing ABI enumeration slots, e.g. EF_MIPS_ABI, which seems to be a value rather than a set of flags, and * all the bits seem to be gone. (looking at the current header, it looks to me like 0x0f000ed8 are still available.) again, i don't know which are reserved by external entites, i.e. MTI or SGI. But it seems that there's still some wiggle-room. cgd >From rth@cygnus.com Tue Aug 08 19:07:00 2000 From: Richard Henderson To: "Chris G. Demetriou" Cc: Andrew Cagney , Nick Clifton , gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: RFA: Recording MIPS ABI selection in binaries Date: Tue, 08 Aug 2000 19:07:00 -0000 Message-id: <20000808190706.A27768@cygnus.com> References: <200008090030.RAA19784@elmo.cygnus.com> <5tittb2pv3.fsf@highland.sibyte.com> <3990B4BE.C2273617@cygnus.com> <5thf8v2oh5.fsf@highland.sibyte.com> X-SW-Source: 2000-08/msg00168.html Content-length: 1316 On Tue, Aug 08, 2000 at 06:49:10PM -0700, Chris G. Demetriou wrote: > And what purpose is there in expressing that a binary uses exactly one > ISA's/CPU's type of instructions, i.e. why should it be encoded the > way it is? Use of an ISA is not exclusive; you can use multiple ISAs > in a single executable, with (strongly desirable) good effect. Actually, this brings up a good point: perhaps this ought to be done per compilation unit rather than for the entire binary. Looking at the dwarf2 spec (and who cares about others), a likely candidate is DW_AT_producer. Then looking at dwarf2out.c, I see /* The MIPS/SGI compilers place the 'cc' command line options in the producer string. The SGI debugger looks for -g, -g1, -g2, or -g3; if they do not appear in the producer string, the debugger reaches the conclusion that the object file is stripped and has no debugging information. To get the MIPS/SGI debugger to believe that there is debugging information in the object file, we add a -g to the producer string. */ if (debug_info_level > DINFO_LEVEL_TERSE) strcat (producer, " -g"); So there's precedent for looking into this string to figure out how the binary may be interpreted. All we'd need, then, is some way to dump the relevant options into this string. r~ >From aoliva@redhat.com Tue Aug 08 22:31:00 2000 From: Alexandre Oliva To: gdb-patches@sources.redhat.com Subject: AM33 simulator clean-up Date: Tue, 08 Aug 2000 22:31:00 -0000 Message-id: X-SW-Source: 2000-08/msg00169.html Content-length: 120 Graham Stott had posted this to a Red Hat-internal mailing list, but it never made it to the CVS tree. Ok to install?