Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADI SHARC Architecture support #593

Merged
merged 6 commits into from
Nov 30, 2023
Merged

ADI SHARC Architecture support #593

merged 6 commits into from
Nov 30, 2023

Conversation

joshchngs
Copy link
Contributor

This PR adds a few architecture-specific constants for the ADI SHARC+ architecture. It uses ELF as the base format for its intermediate and executable objects.

@philipc
Copy link
Contributor

philipc commented Nov 13, 2023

Is there any documentation for the SHARC ELF PSABI?
How have you tested this?

src/write/elf/object.rs Outdated Show resolved Hide resolved
src/common.rs Outdated Show resolved Hide resolved
@joshchngs
Copy link
Contributor Author

Is there any documentation for the SHARC ELF PSABI?

Not as such. There is some public documentation for the official toolchain and processor, which contains some of the information:

There is also some documentation which is only available within the toolchain package itself, in header files, example code, and embedded HTML documentation. I can't share this, but anybody can go see it by obtaining a trial license.

There are some parts, such as the relocation specifics, which are undocumented. I obtained these values through reverse engineering the toolchain output.

How have you tested this?

I'm using this branch from a private crate which serves as the SHARC backend to our in-house compiler. I'm focusing on writing DOJ (the intermediate object format) right now, so that is the well exercised part.

Encoded as normal ELF attributes, with proprietary tags.

I have an implementation of the full encode/decode in a private repo,
which I can share for porting into `object` if needed, but it seems a
bit out of scope.
E.g. a 6-bit PC-relative relocation into a 48-bit instruction has
`size == 6`, not `size == 48`.
As suggested by @philipc. Combined with the previous commit's change to
the meaning of `size` for these relocations, there is no longer any
ambiguity when converting between the 3-tuple and Rel::r_type constants.
As discussed in PR gimli-rs#593

The `_` pattern will take these matches now, so the result is still an
Error, just with a (probably) more truthful message.
@philipc philipc merged commit 99ebe6a into gimli-rs:master Nov 30, 2023
12 checks passed
mcbegamerxx954 pushed a commit to mcbegamerxx954/object that referenced this pull request Jun 15, 2024
* Add Architecture::Sharc
* elf: Add support for SHARC+ relocations
* elf: sharc: add SHT_SHARC_ADI_ATTRIBUTES
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants