-
Notifications
You must be signed in to change notification settings - Fork 31
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
Improve how elf2tab parses ELF files #23
Conversation
Use safer ELF parsing methods to find the fields we need.
Why are the RAM segments different for |
.stack is set to noload and does not generate a segment.
…On Wed, Jun 24, 2020, 3:16 PM Alistair Francis ***@***.***> wrote:
Why are the RAM segments different for libtock-rs?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALGL4QHCFUTRIDXZ3OBYRTRYJGIXANCNFSM4OHCM4MA>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic looks good; the README could use a bit more of an explainer on what's expected to happen when things aren't present.
README.md
Outdated
instead of being position independent. To detect a fixed flash address, elf2tab | ||
looks to see if the flash segment is at the dummy flash address for PIC apps or | ||
not. To detect a fixed RAM address, elf2tab looks for a `_sram_origin` symbol, | ||
and checks if the address matches the dummy RAM address for PIC apps or not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does elf2tab do if there is neither a _sram_origin
symbol nor does the PIC address match? (I'll read the code in a second, but I think the intent should probably be specified here (i.e. will/should it error?))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that would break backwards compatibility. elf2tab just does what it does now: nothing.
// by the app when it first starts. If for some reason an app is PIC and | ||
// wants to use different dummy PIC addresses, then this logic will have to | ||
// be updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not for this PR, but I think this logic shouldn't change; rather these constant should just be exposed as flags.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors d+
Haha, there's no bors ... or even tests (😢) ... in this repo is there |
There are tests! But bors doesn't do anything if there is only one PR/week or month or year. |
208: linker: add sram origin symbol r=bradjc a=bradjc This allows elf2tab to determine what the start of RAM address is when generating a fixed address header in the TBF. See tock/elf2tab#23 and tock/tock#1845. Co-authored-by: Brad Campbell <bradjc5@gmail.com>
This fixes two things: