public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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/

             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).