[PATCH] D13212: [ELF2] - Implemented -e flag

[Rui Ueyama via llvm-commits]

On Mon, Sep 28, 2015 at 10:59 AM, Joerg Sonnenberger <
joerg at britannica.bec.de> wrote:

> On Mon, Sep 28, 2015 at 10:35:45AM -0700, Rui Ueyama wrote:
> > On Mon, Sep 28, 2015 at 9:59 AM, Joerg Sonnenberger via llvm-commits <
> > llvm-commits at lists.llvm.org> wrote:
> >
> > > On Mon, Sep 28, 2015 at 01:33:16PM +0000, George Rimar via llvm-commits
> > > wrote:
> > > > "If there is no symbol named entry, the linker will try to parse
> entry
> > > > as a number, and use that as the entry address (the number will be
> > > > interpreted in base 10; you may use a leading 0x for base 16, or a
> > > leading 0 for base 8)."
> > > >
> > > > But I doubt that it is a real usecase and not sure if it should be
> > > implemented or not ?
> > >
> > > In combination with linker scripts, it can make perfect sense. Many ELF
> > > kernel images are linked that way.
> > >
> >
> > Yes, we eventually need that. But that shouldn't be implemented in this
> > patch and doesn't have to be supported now.
>
> Well, in terms of architecture, the idea would be to keep it as string
> as long as possible and only resolve it just before writing the
> executable header. In that case, it is trivial to do either. It can't be
> easily done in a different way either if you want to support literal
> numbers.


That'd be trivial later, too. Probably the best way to handle both entry
symbol name and entry address in LLD architecture is to use a SymbolBody as
a handle to an entry point symbol whichever its type is. In COFF, we store
a Config member variable to a pointer to a SymbolBody, so that the entry
address is obtained by Config->Entry->getRVA(). We can make the same change
with a simple patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150928/51346168/attachment.html>