RISC-V ELF File Format Spec

774 views
Skip to first unread message

Clifford Wolf

unread,
Aug 17, 2016, 2:31:53 PM8/17/16
to RISC-V ISA Dev
Hi,

the RISC-V spec increasingly contains "auxiliary" information that is not
directly relevant for building a hardware implementation, but is important
for people who want to make software for RISC-V (and integrate those
software components).

I'm of course thinking of e.g. the chapter on the calling convention and
the list of assembler pseudo-instructions.

Are there any plans for also including information about the RISC-V ELF
format in the spec, or is there already a separate document for this, like
with the calling convention before the 2.1 ISA spec release?

(I was wondering about the semantics of the different R_RISCV_PCREL_* ELF
relocation types, but it wasn't so important to me that I would have been
willing to dig into the binutils code and see what the linker does with
those relocations. :)

regards,
- clifford

--
There are only two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.
-- Martin Fowler, intentionally misquoting Phil Karlton

Alex Bradbury

unread,
Aug 17, 2016, 4:22:32 PM8/17/16
to Clifford Wolf, RISC-V ISA Dev, Arun Thomas
On 17 August 2016 at 19:31, Clifford Wolf <clif...@clifford.at> wrote:
> Hi,
>
> the RISC-V spec increasingly contains "auxiliary" information that is not
> directly relevant for building a hardware implementation, but is important
> for people who want to make software for RISC-V (and integrate those
> software components).
>
> I'm of course thinking of e.g. the chapter on the calling convention and
> the list of assembler pseudo-instructions.
>
> Are there any plans for also including information about the RISC-V ELF
> format in the spec, or is there already a separate document for this, like
> with the calling convention before the 2.1 ISA spec release?
>
> (I was wondering about the semantics of the different R_RISCV_PCREL_* ELF
> relocation types, but it wasn't so important to me that I would have been
> willing to dig into the binutils code and see what the linker does with
> those relocations. :)

A separate document for this doesn't exist for this currently, but
there's certainly demand for it. It's one of those things that just
needs contributions. Arun (CCed) has mentioned this need at least at
the last two RISC-V workshops. I haven't got round to the mnemonics
yet in my RISC-V LLVM work, but such a document would certainly be
helpful to me and to others who are reviewing patches. I hope I'll be
able to contribute to drafting such a document as a side effect of the
LLVM work, though a full assembly programmer's manual / psABI is a
project that's going to need a group of contributors.

If anyone has already started something towards this goal, please do share.

Best,

Alex

黃柏瑋

unread,
Mar 2, 2017, 4:35:35 AM3/2/17
to RISC-V ISA Dev, clif...@clifford.at, arun....@gmail.com
Hi all,
Continuing this thread, are we going to discuss ABI and ELF spec for RISC-V in the privileged arch meeting?
Moreover, in the last workshop, I remembered that somebody (maybe yunsup?) has talked about a place or a group to hold or list the open source project for RISC-V.
Is that exist?
Thanks,
Po-wei Huang

asb於 2016年8月18日星期四 UTC+8上午4時22分32秒寫道:

Andrew Waterman

unread,
Mar 2, 2017, 4:51:00 AM3/2/17
to 黃柏瑋, RISC-V ISA Dev, Clifford Wolf, Arun Thomas
Hi Po-wei,

I do not think that the ABI and ELF spec are germane to PrivArch's
agenda. I am not sure which working group is most appropriate for
these discussions, but in the mean time, the github issue tracker for
the ELF psABI spec is a good place to contribute:
https://github.com/riscv/riscv-elf-psabi-doc/

Andrew
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/1a537e90-e94c-42c5-bbd6-0516c4e63bbb%40groups.riscv.org.

黃柏瑋

unread,
Mar 2, 2017, 5:00:28 AM3/2/17
to Andrew Waterman, RISC-V ISA Dev, Clifford Wolf, Arun Thomas
Hi andrew,
Thanks for your reply. I will check the ELF.
I’m not sure which group will be appropriate, but I believe it’s quite important. Maybe software toolchain group? I will probably ask them later.
How about the open source list? Have you got any information? If that is not existed, I’ll probably do a list on my own blog.
Thanks for your patient help.
Best,
Po-wei Huang

Andrew Waterman

unread,
Mar 2, 2017, 6:03:16 PM3/2/17
to 黃柏瑋, RISC-V ISA Dev, Clifford Wolf, Arun Thomas
It definitely overlaps with the software working group's agenda. I'll
bring this up at the next meeting.

Rodney Brown

unread,
Mar 2, 2017, 11:58:02 PM3/2/17
to RISC-V ISA Dev, poweih...@gmail.com, clif...@clifford.at, arun....@gmail.com


On Friday, 3 March 2017 10:03:16 UTC+11, andrew wrote:
It definitely overlaps with the software working group's agenda.  I'll
bring this up at the next meeting.

Add a placeholder for FDPIC support for RV32EC/RV32C in the ELF spec?
 
Binutils: Draft SH uClinux FDPIC ABI
...
This document describes extensions (and some minor changes) to the
existing SH ELF ABI (as used on GNU/Linux) required to support the
implementation of shared libraries on a system whose OS (and hardware)
require that processes share a common address space. ...

But see also Binutils: Re: SH FDPIC ABI spec/binutils and kernel conflict on flag definitions

Whether it would be used enough to warrant the effort...

Michael Clark

unread,
Mar 3, 2017, 12:34:53 AM3/3/17
to Rodney Brown, RISC-V ISA Dev, poweih...@gmail.com, clif...@clifford.at, arun....@gmail.com
Whether it would be used enough to warrant the effort…

FDPIC looks interesting!

I guess it depends on the prevalence of RISC-V implementations without MMUs.

I see that FDPIC decouples the text and data segment so that .data and .bss can no longer be referenced relative to the .text segment to support co-resident programs using the same shared library in a common address space. It seems all data references become GOT relative. Here is another good summary of FDPIC: http://nommu.org/

Michael.

Reply all
Reply to author
Forward
0 new messages