This is the mail archive of the firstname.lastname@example.org mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
> As I read it, it's a bit different from the OLF proposal. SCO is > defining EI_OSABI as indicating whether the file conforms to the > standard ELF format. A value of 0 (ELFOSABI_SYSV) indicates that the > file does conform. For EI_ABIVERSION, a conforming application must > use 0. Our files do conform to the specification (I hope), so it is > correct for us to use 0 for both. I don't know how to read it. The "standard" is hopelessly vague (if a unilaterally published document can be called a standard). They don't clearly define an ELF standard independent of the SVR4 Unix ABI standard, so when they say "this specification" I don't know whether that means "the ELF specification" or "the SVR4 ABI specification". One sentence is suggestive but mysterious: Some fields in other ELF structures have flags and values that have platform specific meanings; the interpretation of those fields is determined by the value of this byte. It is certainly not the case that we (intentionally) use on GNU platforms different "platform specific meanings" for any ELF structure flags or values that are in the ELF spec. Aside from SVR4, the one meaningful value they list is HPUX. Do you know of any incompatibilites between HPUX's use of ELF and other ELF implementations? That might suggest they are talking about file format compatibility rather than ABI compatibility. If that is so, this is an utterly stupid addition. If HPUX ELF is not compatible with the existing ELF spec, then HP should use a different EI_VERSION value. They have conveniently added fields to the header without changing the EI_VERSION number (which the original spec suggests is intended for such changes), taking bytes from the EI_PAD area that the old spec reserves to be zero and making zero mean SVR4. If they are talking about the ABI, then that retroactively declares all old ELF binaries to be "officially marked" as wanting the SVR4 ABI; that is bogus. > However, we could perhaps ask email@example.com to define > ELFOSABI_LINUX, and define that as being the same as the standard, but > using the Linux API. Similarly for other free operating systems. The community of OS projects using ELF has already adopted an ABI identification mechanism, using PT_NOTE. Someone from SCO once said they would use that scheme too. But now this totally other thing comes out in this new spec that, as far as I know, noone in the free OS community was ever asked about. Since it says it's a draft, perhaps we can get them to clean up and clarify the draft and take notice of the rest of the world that is using ELF. A so-called standard is not meaningful or important to adhere to just because an organization publishes it, and a specification is certainly not a standard just because one vendor unilaterally declares it so. We chose to use ELF as we do now on its merits, and in adding the ABI notes we used a mechanism that fit in their spec and seemed in the spirit of the spec, to be nice and try to cooperate helpfully to interoperate. Now they want to promulgate a new spec with changes that are not in the spirit of the old spec and don't use its prescribed procedures for change. I wish they would clarify their specs to clearly specify the ELF file format and special section formats unambiguously and independent of the operating system ABI specification. That would allow a compilation toolchain, linker, and dynamic linker, to be clearly correct in their processing of ELF files independent of how they are implemented and what ELF files they might be processing. I don't know if anyone else attempts to provide such a thing, but GCC, GNU binutils, and the GNU dynamic linker that's provided in the GNU libc package (but usable independent of what libraries it loads, as well as being easily portable), together form a fully complete, correct (we hope) to spec, and highly-portable (not to mention high-quality, well-supported, and permanently free) set of ELF tools for a wide variety of processors. I think we are all proud of this communal work and the high standard of cross-platform uniformity and correctness we endeavor to achieve, and it would be nice to have an unambiguous standard to which we can be definitively correct and measured against our proprietary peers. I'm now going to proceed on the assumption that EI_OSABI is intended to indicate the operating system ABI expected by the program. I make this assumption both because of its name, and because adding two fields whose sole meaning is "yes, really, the same file format spec" is just plain idiotic and I'm giving SCO a little (perhaps too much) credit for not being chalk full of complete idiots. If we can figure out how on earth there can be a meaningful indicator specified in a standard format that some parts of the format are nonstandard, maybe it will be become more clear. Is there anyone with a brain at SCO or HP that we can ask what the story on this magic HPUX compatibility value and the horrifying "platform specific meanings" vagueness? I agree that the simple two-byte addition in the file header padding area is nicely compact and easy to check, and if specified properly can be appropriately and fairly done without changing the header version numbers. What "specified properly" means is full unambiguous backward compatibility with the reality of the old specification. That is, a value of zero in those positions as required by the old spec should mean "old spec, ABI not specified" and the suggested practice in encountering such would be to look for a PT_NOTE like every free OS has been using unambiguously for many months now. It is completely bogus to retroactively declare existing ELF binaries to mean something the format didn't mean in the original spec. If old SVR4 systems complied with the spec, they ignore those bytes anyhow, so if they thought all ELF binaries were SVR4 ABI binaries, they won't care that new SVR4 ABI binaries have a nonzero value in that byte.