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

Add Reloc::Data, which supports an addend #75

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Aaron1011
Copy link

Fixes #71

This commit creates a new variant 'Data' of the 'Reloc' enum.
This can be used to define a relocation to a data section entry
with a custom addend.

With this change, it's now possible to create a relocation representing
an index into an array or some other structure, where the addebd
represents the offset from the base.

I've only implemented this for ELF. Unfortunately, I'm completely
unfamiliar with Mach-O, and don't have an OS X instance available to
test with.

Additionally, I've moved the magic '-4' into a constant, and added some
documentation explaining where it comes from (though I may have a few
details wrong).

I've also tweaked the binary created by src/bin/main.rs to demonstrate
using Reloc::Data

Fixes m4b#71

This commit creates a new variant 'Data' of the 'Reloc' enum.
This can be used to define a relocation to a data section entry
with a custom addend.

With this change, it's now possible to create a relocation representing
an index into an array or some other structure, where the addebd
represents the offset from the base.

I've only implemented this for ELF. Unfortunately, I'm completely
unfamiliar with Mach-O, and don't have an OS X instance available to
test with.

Additionally, I've moved the magic '-4' into a constant, and added some
documentation explaining where it comes from (though I may have a few
details wrong).

I've also tweaked the binary created by src/bin/main.rs to demonstrate
using Reloc::Data
@@ -37,6 +37,29 @@ type Relocation = goblin::elf::reloc::Reloc;
type Symbol = goblin::elf::sym::Sym;
type Section = SectionHeader;

/// When we have a link from a function on X86,
/// we create a relocation entry that modifies
/// the PC-relative 32-bit immedaite value of an instruction. (e.g.'call')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*immediate

@philipc
Copy link
Collaborator

philipc commented Apr 5, 2019

This looks like it should work for ELF x86-64.

However, I think we need to figure out how this is going to work for ELF x86 and Mach-O. The difference being that unlike ELF x86-64, these do not store the addend in the relocation. Note that this is a problem for the Debug relocations too (https://github.com/bjorn3/rustc_codegen_cranelift/issues/303).

Also, I don't think it makes sense for Data and Debug to be separate variants. The only reason that Debug is currently a separate variant is because Auto wasn't generic enough. So I see two options: added size and addend parameters to Auto (maybe using a builder to make this more convenient), or at least change Debug to a variant that supports the Data section too.

@Aaron1011
Copy link
Author

The difference being that unlike ELF x86-64, these do not store the addend in the relocation

Which relocation types are you referring to? From what I can see, R_386_32, R_386_PC32, R_386_GOT32 (and others) have an explicit addend for 32-bit ELF.

@philipc
Copy link
Collaborator

philipc commented Apr 5, 2019

I mean that x86-32 uses .rel instead of .rela, and faerie currently has no support for writing addends except in the relocation entry.

// Having a user-supplied addend doesn't make sense here,
// as it would cause us to move within the GOT itself -
// not relative to the address stored in the GOT entry.
assert!(addend == 0, "Addend must be 0 for reloc {:?}", l);
Copy link
Owner

@m4b m4b Apr 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the way we've been doing this, or at least I thought, perhaps things have changed:

  1. artifact is the only real "entry" to the various backends.
  2. consequently most user level errors are attempted to be caught during artifact construction, and a Result is returned.
  3. asserts in the backends are to ensure that contracts between the artifact front end and the backend are enforced at the artifact front end via result. I.e., they're programmer invariants, not user input invariants. So if there is some kind of user introduced error that is backend specific, but not enforced by artifact (because it can't, for example), then we should return a result, instead of asserting.

So I bring this all up because this assert looks like its enforcing user inputs to have certain properties, which means it should be a returning a Result.
That being said, I can't see on this git review if this function returns a Result, so maybe you didn't feel like changing the return type, etc., which is reasonable, but then we should revisit (at some other PR perhaps) this functions return type if user errors are being asserted against.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't return a Result (FYI github lets you expand the review code to see this).

@m4b m4b requested review from pchickey and sunfishcode April 6, 2019 18:20
@m4b
Copy link
Owner

m4b commented Apr 6, 2019

cc @sunfishcode @pchickey
Do you all have any ideas on what is best strategy here, re @philipc comment, etc.

@m4b
Copy link
Owner

m4b commented Apr 29, 2019

What happened here? Seems there were some unresolved questions? How mergeable/close is this?

@m4b
Copy link
Owner

m4b commented May 31, 2019

Ping all concerned parties; same comment as above, this PR is getting stale :)

@philipc
Copy link
Collaborator

philipc commented May 31, 2019

You could just go ahead and merge this. It's no worse than the existing Reloc::Debug variant.

@sunfishcode sunfishcode removed their request for review July 12, 2019 00:41
@sunfishcode
Copy link
Collaborator

I myself don't feel I have a clear view of how faerie's "automatic" approach to relocations should work, so I'm stepping back as reviewer here.

@pchickey pchickey removed their request for review December 6, 2022 20:28
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.

Implement addends in data section relocations
5 participants