From: Alexander Fedotov <alfedotov@gmail.com>
To: binutils@sourceware.org, gdb@sourceware.org
Subject: ELF program header in baremetal
Date: Mon, 21 Oct 2019 10:18:00 -0000 [thread overview]
Message-ID: <CAN8C2CrxTvj4mgiTQjEiYo9icdRJvk8kCWa=n0fF0WnRmFUx1Q@mail.gmail.com> (raw)
Hello Binutils and GDB folks.
There is a question regarding p_align in ELF Program Header.
Whilst this parameter is understandable for loading application in OS,
there is no clear picture for baremetal - must debugger to follow ELF
specification or not.
Seems like we’ve been lucky in most cases until alignment being increased
to 64kB [1] since it was small enough. Now it is not.
Below is a real case on the MCU with Arm core onboard and small memory amount.
Linker script is:
m_interrupts (RX) : ORIGIN = 0x1FFF8000, LENGTH = 0x00000400
m_text (RX) : ORIGIN = 0x1FFF8400, LENGTH = 0x00007C00
Program Header:
LOAD off 0x00000000 vaddr 0x1fff0000 paddr 0x1fff0000 align 2**16
filesz 0x00008400 memsz 0x00008400 flags r--
LOAD off 0x00008400 vaddr 0x1fff8400 paddr 0x1fff8400 align 2**16
filesz 0x00000570 memsz 0x00000570 flags rwx
LOAD off 0x00010000 vaddr 0x20000000 paddr 0x20000000 align 2**16
filesz 0x00000424 memsz 0x00007000 flags rw-
private flags = 5000200: [Version5 EABI] [soft-float ABI]
With the given Program Header non-GDB debuggers loads non-existent memory
and throws an error. Another ones loads this ELF with warning but with
Verification error after that. I haven’t analyzed how GDB address this,
but somehow it is not affected. Maybe GDB just ignore PH and loads sections.
Anyway such a different behavior is odd.
Another case is multicore wen we have multiple separate ELF files. Loading
one-by-one can overwrite previously loaded text/data.
Similar case with bootloader overwriting [2].
My proposal is to set ELF_MAXPAGESIZE to smallest value for baremetal
configuration.
gABI states:
Values 0 and 1 mean no alignment is required. Otherwise, p_align should
be a positive, integral power of 2, and p_vaddr should equal p_offset,
modulo p_align.
Forcing -max-page-size to 0/1 doesn't work unfortunately. It still generates
non-existent segments.
Best regards,
Alex
---------------
[1] https://patches.linaro.org/patch/32565/
[2] https://www.tablix.org/~avian/blog/archives/2012/11/gnu_linker_and_elf_program_header/
next reply other threads:[~2019-10-21 10:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-21 10:18 Alexander Fedotov [this message]
2019-11-11 14:58 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN8C2CrxTvj4mgiTQjEiYo9icdRJvk8kCWa=n0fF0WnRmFUx1Q@mail.gmail.com' \
--to=alfedotov@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).