search for: openssl1.0

Hi Rui, We met a lld-link crash problem when build 32bits openssl1.0 with LTO in uefi firmware. We narrow down and figure out a simple test case to reproduce this problem as blow. Please advise. Thank you! $ cat main.c void TlsDriverEntryPoint () { unsigned char *ret = 0; const unsigned char cryptopro_ext[17] = {0x00,0x00,0x00,0x00,

Hi Steven, One thing I noticed is that you are defining `memcpy`, which clang has an intrinsic with the same name. Can you try renaming it to a random name, like `foobar`, to see if the problem still exists? On Tue, Jul 16, 2019 at 10:10 AM Shi, Steven <steven.shi at intel.com> wrote: > I’ve submitted a BZ for this issue as below: > > > > Bug 42626 - lld-link crash when

lld should not crash in this case (so that's a bug that needs fixing), but setting it aside, did you try adding `-fno-builtin` to clang so that clang doesn't handle `memcpy` as a built-in function? On Tue, Jul 16, 2019 at 8:46 PM Shi, Steven <steven.shi at intel.com> wrote: > Hi Rui, > > For the test case in my previous email, if I change the `memcpy` to > `foobar` in

Yeah, it crashes indeed. I can reproduce the problem locally. Let me see what is going on. On Tue, Jul 16, 2019 at 9:00 PM Shi, Steven <steven.shi at intel.com> wrote: > In my previous test case, after add the `-fno-builtin` to clang then > build, the lld-link still has same crash as below: > > > > $ make > >

Usage of the builtin appears independent of LTO, see below. With any of -fno-builtin, -fno-builtin-memcpy, and -ffreestanding, which are all typically used to prevent usage of memcpy calls, we still always get a memcpy builtin in TlsDriverEntryPoint(). I see this even without -flto (e.g. try with just -emit-llvm). I guess it is because this memcpy is not coming from the original source, but