This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFA: Recording MIPS ABI selection in binaries


Jeffrey A Law <law@cygnus.com> writes:
>   > 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.
> Correct.  For a number of platforms (such as many embedded MIPS chips) the
> GNU tools defined the de-facto ABI.

yes.  (Indeed, for the binaries i spend every day working with, it is.
8-)

however, that doesn't mean that it shouldn't be improved.  (and,
certainly, a backward-compatible mechanism would be best.)

I guess what i'm looking for here is for some hard-core MIPS-heads to
provide me with the information I asked about earlier, specifically
which of the flags really are used (since according to the elf headers
some still appear free, as far as I can tell), and which are
"specified" by "standards" (actual standards or unflexible OSes for
MIPS), and then to be open to discussion about how the flags should
evolve from here.

I'm willing to code up patches, certainly, if there's an audience
who's likely to be receptive to them and they're considered "the right
thing" by the community.


>   > : 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.
> Yup.  Or we can put arbitrary contents into a non-loadable section to
> record information we care about.

Right, so, I was going to let the scalable comment pass, but I've
changed my mind.  8-)

It's scalable in the number of different types of things you can
represent, but not in the amount of work needed to correctly operate
on those types of information.  For instance, you can represent an
infinite number of ABIs if you so choose, but in order to have proper
operation (which avoids mixing of ABIs) you need to search for all of
those section names.

For the particular case of ABI-related bits, the flags field is, in my
opinion, better, and it looks like there's space!

For other things, e.g. the ISA type, sections like these or debugging
information as rth has suggested are more appropriate (and, I defer to
his opinion, certainly 8-).



chris

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]