Default entry point for ELF shared objects

[Hans-Peter Nilsson]

On Thu, 16 Sep 2021, Paul Koning wrote:

>
>
> > On Sep 16, 2021, at 11:14 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> >
> > On Thu, 16 Sep 2021, Florian Weimer via Binutils wrote:
> >
> >> * Fangrui Song:
> >>
> >>> ...
> >>> This behavior is documented at https://sourceware.org/binutils/docs/ld/Entry-Point.html
> >>>
> >>> "the address of the first byte of the ?.text? section, if present;"
> >>>
> >>> The rule is quite ad-hoc and I'd support the removal.
> >>
> >> I saw that.  I still wonder where it came from originally.  It seems
> >> more like something for a bare-metal target.  Maybe it can be kept for
> >> those,
> >
> > Even if so, IMHO it should be updated to be "the text segment"
> > or words to that effect, as the .text *section* is likely just
> > main code located after .startup or .init or similar.
>
> A default entry point really doesn't make any sense for any
> target, bare metal or otherwise.  Yes, it's possible such a
> random guess is the right answer some of the time, but clearly
> any build can always supply an explicit start address -- and in
> my view that should be required.
>
> As an example, the DEC object format has a special code point
> meaning "no start address", and that is the default.

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*.  This
because code for embedded targets is likely linked into one blob
with the .text section being located only after other named
sections in the text segment and the start address being the
first address of that blob.

Perhaps we just talk past each other.

brgds, H-P