public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Default entry point for ELF shared objects
@ 2021-09-13  7:55 Florian Weimer
  2021-09-15 16:49 ` Fangrui Song
  0 siblings, 1 reply; 10+ messages in thread
From: Florian Weimer @ 2021-09-13  7:55 UTC (permalink / raw)
  To: binutils

BFD ld currently sets a non-zero entry point address for ELF shared
objects even if the object does not have a _start symbol.

Is there a reason for this behavior (particularly for ELF ET_DYN
output)?

On Linux, the kernel will happily load and execute shared objects using
this entry point address, typically leading to crashes.

If the entry point address in the ELF header were zero, it might be
possible to detect the missing entry point, and refuse to execute the
shared object as if it were a program.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: Default entry point for ELF shared objects
@ 2021-09-17  5:40 dvalin
  0 siblings, 0 replies; 10+ messages in thread
From: dvalin @ 2021-09-17  5:40 UTC (permalink / raw)
  To: binutils


  On 16.09.21 19:01, Florian Weimer via Binutils wrote:
  > * Hans-Peter Nilsson:
  >
  > > Let me rephrase: since we *can't* say "no start address", a
  > > guess that is much more likely to be correct, is "the address
of
  > > the first byte of the text *segment*" (for formats where that
  > > term applies) than the that of the .text *section*.
  
  The linker script has to put .vector and .init_n input sections
into the .text 
  output section, if it doesn't place them first in the text segment,
so in my  decades of embedded experience, it comes down to how you
hack the  script.
  > Just to be clear, ELF specifies 0 as “no start address”. 
And I'm only
  > interested in ELF these days …

  Is it then not ideal to leave things as they are? With “no start
address”
  specified, ELF defaults to indicating “no start address”.

  The status quo evidently emanates from the glory days when bare
metal
  applications were all there was. (And still is here, 40 years
later.)

  On reset, many a microprocessor sets the program counter to zero,
which
  is the start of the text segment. (OK, that'll be the start of the
  interrupt vector table in many cases that I've encountered, and
hardware 
  reset can be viewed as the mother of all interrupts.)

  There are a few exceptions, requiring some target-specific start
address,
  sometimes selectable between piggy-in-the-middle and a bit short of
top
  of the address space. Exceptions have always required an explicit
start
  address, and there is nothing to take exception to there.

   So the safest course is to not rock the boat. That said, a change
from 
   hard-coded zero to start of the text segment ought to have zero
negative   effect in the common low-end embedded case, and may
beneficially 
  serve a number of non-zero start targets. (E.g. Boot from high
ROM,  then copy at least vectors down to zero address, possibly
followed by  the whole app. There, text LMA is ROM, VMA is in RAM for
all but the  bootstrap.)

  /2c

Erik

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-09-17  5:40 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-13  7:55 Default entry point for ELF shared objects Florian Weimer
2021-09-15 16:49 ` Fangrui Song
2021-09-16  5:01   ` Florian Weimer
2021-09-16  7:41     ` Andreas Schwab
2021-09-16 15:14     ` Hans-Peter Nilsson
2021-09-16 16:39       ` Paul Koning
2021-09-16 16:54         ` Hans-Peter Nilsson
2021-09-16 17:01           ` Florian Weimer
2021-09-16 17:02           ` Paul Koning
2021-09-17  5:40 dvalin

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