[cfe-dev] Static linking a program

[Wink Saville via cfe-dev]

On Thu, Jul 5, 2018, 2:11 AM Peter Smith <peter.smith at linaro.org> wrote:

> On 4 July 2018 at 23:20, Wink Saville via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > Executive summary: In _dl_get_origin lld is linking a call to mempcpy
> which
> > I'd call "thunking code" as it returns in rax the address of the code
> > that should be called instead of the address of the next available
> > address of the
> > destination buffer. And specifically, since rax is pointing at code,
> when a zero
> > is stored to try to terminate the string we seg fault.
> >
> > I'd be glad to file a bug if you like.
>
> I think that would be the best idea. As Rui suggested earlier it would
> be helpful to add -Wl,--reproduce=repro.tar so that all the libraries
> are included. My suspicion here is that this is related to a newer
> version of libc.a as I can't reproduce a crash on my Ubuntu 16.04
> machine. Looking at an annotate of some of the glibc source it looks
> like indirect functions (ifunc) have been used with __mempcpy have
> been added relatively recently. The ifunc resolution mechanism is not
> particularly well documented so it is possible that there is a case
> that LLD isn't handling as expected.
>
> Unfortunately I can't tell much from the disassembly of the final
> image about what the linker has got wrong. We really need to see the
> input objects and how LLD and Gold differ in the resolution of symbols
> and relocations to work that out.
>
> Sorry I can't be of much more help here.
>

I'd added the --reproduce tar file to a previous post but it looks like it
got stuck being approved by the list admin,
I'll add it to the bug report.

I'll file the bug at https://bugs.llvm.org, is there someone I should
assign the bug to?

-- Wink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180705/ea2634c3/attachment.html>