ELF ABI Documents
I'm on a bit of a quest for accurate documentation.
This started when I was starting to hack klibc and had to go digging for a bunch of information in a pile of different documents. What I'd like to do is write the LSB document for parisc so that there's a single accurate place to refer to for calling conventions / syscall information, etc.
It's most common in the LSB specs to refer to the ELF psabi document where possible. http://refspecs.freestandards.org/elf/elf-pa.pdf seems to be a copy of the psabi document, but when checking with some folks, it looks like the document isn't a reflection on reality for parisc-linux. The question is, should the document be updated to reflect reality, should we slowly change to match the document, or should I just not refer to the psabi document much when writing the LSB document?
Tks,
Jeff Bailey
Signature · 4 lines
Although when you're in the situation that RMS is telling you that you're being too ideological about freedom, maybe, just maybe, it's true. - Matthew Wilcox
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 8 lines
It's most common in the LSB specs to refer to the ELF psabi document where possible. http://refspecs.freestandards.org/elf/elf-pa.pdf seems to be a copy of the psabi document, but when checking with some folks, it looks like the document isn't a reflection on reality for parisc-linux. The question is, should the document be updated to reflect reality, should we slowly change to match the document, or should I just not refer to the psabi document much when writing the LSB document?
First of all, I want to say that such a document would be wonderful to have!
I think the ELF-PA document corresponds mostly with what we do on parisc-linux. There are some things we don't implement (e.g. I don't think we have PCREL14WR/PCREL14DR), and we have made some enhancements in other areas (e.g. TLS relocations). The only thing that I know of where we don't follow the spec is how we handle SEGREL32 - we don't use a SEGBASE relocation to set the segment base, but rely on other information from the ELF headers.
I don't think the ELF spec talks about calling conventions and syscall conventions though. For that, parisc-linux mostly follows the SOM spec for calling conventions
(http://ftp.parisc-linux.org/docs/arch/pa-runtime-32-SOM.pdf)
A document about hppa ABI will not be complete without some discussion about the hppa unwinding mechanism too.
my 2 cents :)
randolph
Signature · 7 lines
Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/ _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 4 lines · Randolph Chung
I don't think the ELF spec talks about calling conventions and syscall conventions though. For that, parisc-linux mostly follows the SOM spec for calling conventions
(http://ftp.parisc-linux.org/docs/arch/pa-runtime-32-SOM.pdf)
Right. This is where the LSB document comes it. It does wind up defining those for Linux at least. The "Mostly follows SOM" is largely what's inspired me on this quest. I'd love to see a definitive document that defines this and am willing to go through the effort to do it.
Tks,
Jeff Bailey
Signature · 4 lines
Although when you're in the situation that RMS is telling you that you're being too ideological about freedom, maybe, just maybe, it's true. - Matthew Wilcox
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 9 lines
Quoted 4 lines
I don't think the ELF spec talks about calling conventions and syscall conventions though. For that, parisc-linux mostly follows the SOM spec for calling conventions
(http://ftp.parisc-linux.org/docs/arch/pa-runtime-32-SOM.pdf)Right. This is where the LSB document comes it. It does wind up defining those for Linux at least. The "Mostly follows SOM" is largely what's inspired me on this quest. I'd love to see a definitive document that defines this and am willing to go through the effort to do it.
I think what is needed is a SYSV PS ABI for PA-RISC. It probably shouldn't be an LSB document. Typically, the LSB only adopts a subset of any particular specification, and in the case of the PS ABIs, references the documents for the various processors currently specified by the LSB. The IA64 document is probably the closest to what's needed for PA-RISC although it can be simplified. It was written jointly by HP and Intel.
It probably would be best to obtain the support of HP in doing this. One of the criticisms of the LSB is that it simply documents what is and in large measure it just refers to other specifications. Whereas, specifications such as POSIX have been written by people aware of the subtle tradeoffs between different implementations and they try to actually specify an implementation. If it's possible to obtain full community support, it's more likely that the document would be useful and a guide to implementors. However, just documenting what is would be useful.
The PA-RISC ABI isn't completely static. For example, I changed the passing of complex values in GCC 4.1 so that they are now treated in the same manner as aggregates. I think it's also fair to say that the TLS implementation is far from finalized.
As noted, the HP ELF documents aren't completely up to date and they don't fully match the current headers provided with HP-UX. For example, there are now note sections for PA-RISC. It would be useful if these documents could be updated as well but this would require permission from HP because of the copyright issues.
The HP ELF implementation differs in some significant ways from that in linux. Areas that come immediately to mind are weak symbol support, program startup, TLS implementation, memory model, debug support, etc.
Quoted 1 line
Quoted 1 line
From my perspective, a well written PS ABI for PA-RISC would certainly
be useful. I suspect HP dropped work in this area because of its decision to phase out PA-RISC. This is certainly a challenging project but maybe once the scope is defined the rest will follow. If you work fast, you might beat implementation of a 64-bit PA-RISC runtime for linux!
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 1 line · John David Anglin
I think what is needed is a SYSV PS ABI for PA-RISC. It probably shouldn=
't
Quoted 6 lines
be an LSB document. Typically, the LSB only adopts a subset of any particular specification, and in the case of the PS ABIs, references the documents for the various processors currently specified by the LSB. The IA64 document is probably the closest to what's needed for PA-RISC although it can be simplified. It was written jointly by HP and Intel.
The SYSV psABI for HP PA-RISC is going to be a very messy thing to start wi= th.
I whole heartedly recommend that Jeff begin work by writing the ELF psABI for hppa and perhaps after that moving towards the SYSV psABI. The LSB documentation will then be a reference to the SYSV psABI and the ELF psABI documents.
So Jeff, care to whip up a document that is a copy of the elf-pa.pdf and we can start commenting on what's wrong with the document?
What document format are you going to use? I recommend openoffice or tex.
List of the relocs we handle:binutils/include/elf/hppa.h
This file lists our relocs and their values. With comments about
their processing.binutils/bfd/elf-hppa.h
This file contains the relocs howto showing if some are unimplemented. (elf_hppa_final_write_processing): Contains flag settings for the elf hea=
der.
Cheers,
Carlos.
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
"John David Anglin" writes...
Quoted 2 lines
One of the criticisms of the LSB is that it simply documents what is and in large measure it just refers to other specifications.
1) The LSB is a trailing-edge standard, they don't "invent" standards, they just document the standards that are accepted and in use. The work coming up with new standards is being done elsewhere. (X.org and freedesktop.org for example)
2) Referring to other specs is a good thing, why reinvent the wheel?
Quoted 3 lines
Whereas, specifications such as POSIX have been written by people aware of the subtle tradeoffs between different implementations and they try to actually specify an implementation.
To be fair, the LSB is in a hard position. On one hand you have application developers demanding an implementation "We want a solid predictable implementation that we can test on" and on the other you have the Linux distros screaming "Don't take away our right to innovate! Just stick to documenting interfaces and we'll make sure our implementations are compliant with them". What the LSB has done to try and balance in the middle is define a "sample implementation" rather than a "reference implementation". The LSB gets asked once a month "can't you just get all the Linux distros to agree on an implementation, or declare one of them the winner that everyone should use?" IMO the UnitedLinux, DCC, and UserLinux consortiums were all created with that as a goal.
There is also some communication between the LSB workgroup and the Austin Group and they are both benefitting from the other's work.
Quoted 4 lines
If it's
possible to obtain full community support, it's more likely that the document would be useful and a guide to implementors. However, just documenting what is would be useful.
Here, here! And don't worry about doing the work via the LSB, just produce the standard and the LSB will adopt it when it makes sense.
Signature · 8 lines
Matt Taggart [email protected] _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 2 lines
There is also some communication between the LSB workgroup and the Austin Group and they are both benefitting from the other's work.
I'm aware of this and the efforts to align POSIX and the LSB where differences exist. The majority of areas where differences exist between POSIX and linux are resolved in current implementations. Thus, it appears that the standards can be aligned in future updates without too much difficulty.
FWIW, I personally believe that the development of the LSB was a useful effort. However, as you know, one of Austin Group participants
believes the LSB to be useless... Time will tell.
Quoted 7 lines
Quoted 4 lines
If it's
possible to obtain full community support, it's more likely that the document would be useful and a guide to implementors. However, just documenting what is would be useful.Here, here! And don't worry about doing the work via the LSB, just produce the standard and the LSB will adopt it when it makes sense.
It would be a significant achievement if production of these documents allowed PA-RISC to become part of the LSB standard! I think it fair to say that almost all (all?) of the processor specific documents referenced by the LSB were developed by commercial entities rather than the open source community at large.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Quoted 2 lines
It's most common in the LSB specs to refer to the ELF psabi document where possible. http://refspecs.freestandards.org/elf/elf-pa.pdf seems
The latest version is here:
http://ftp.parisc-linux.org/docs/arch/elf-pa-hp.pdf
HP and Intel also developed a generic specification for the ELF-64 object file format, and a version containing HP and HP-UX extensions.
Quoted 6 lines
to be a copy of the psabi document, but when checking with some folks, it looks like the document isn't a reflection on reality for parisc-linux. The question is, should the document be updated to reflect reality, should we slowly change to match the document, or should I just not refer to the psabi document much when writing the LSB document?
None of the above mentioned documents appear to contain a copyright notice. However, this may no longer be an absolute requirement under US copyright law. In as much as a linux document is likely going to have to utilize material from the above, it probably would be wise to get the written approval from HP before proceeding. It might also be necessary to get Intel's approval if the document also attempts to specify ELF for 64-bit linux. Of course if you just reference these specifications and point out differences, this problem can be avoided.
Dave
Signature · 6 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) _______________________________________________ parisc-linux mailing list [email protected] http://lists.parisc-linux.org/mailman/listinfo/parisc-linux