Verified this works fine when build with Clang/LLD 8.0.0. So it's probably an LLD 7.0.0 bug.

In the future, please use component "Tools>ChromeOS-Toolchain"

We are working on the toolchain roll. should happen within couple of weeks.

thanks Yolanda!

Thanks Luis. I will select the recommended component next time!

Hi, Luis

Do you have plan to upgrade to LLD 8.0.0?
Recently we also encountered runtime issues when build chrome with the prebuilt LLD 7.0.0 in chroot. 

With ChromeOS version R71-11042, the chromeos image cannot install correctly and caused screen flickering.
With ChromeOS version R71-11078, the chromeos image can be installed, but Speedometer2.0 test cannot finish and quit unexpectedly.

Are you aware of these issues relate to LLD?

In addition, I created another default linker script generated with compatible linker options used in chrome build. The original one was generated without any linker options that has conflict with existing ones. It caused chrome cannot load after installation. With the updated one, it passed both build and all benchmark tests successfully.
Again, this only works with LLVM/LLD 8.0.0 presently.

Thanks
Yolanda

Deleted: chrome.linkerscript_R71_default 8.6 KB

chrome.linkerscript_R71_default 8.6 KB Download

Yolanda, 

cc cmtice@

thanks for the work on this.

We are looking at a bug with LLD, the symtom is that  chrome crashes when we try to logon. This problem only happens when we try to build with CFI. 
Otherwise, LLD seems to work fine for us. 

I believe Caroline has tried latest LLD but it is worth trying again.
And we can try with your linker script. 

Caroline, can you please try and update the results in this bug?
Yolanda, can you please make sure that you are building with cfi enabled? 
(it should be the default now, but make sure it is the case for you in your ebuild file).

I have the differences we are seing are not related to USE="chrome_internal"

Hi, Luis

Thanks for looking into this.

I set USE="afdo_use lld -gold thinlto". Currently AFDO seems not the default.

Checked my ebuild script, seems cfi is enabled:
IUSE="
    afdo_use
    +accessibility
    app_shell
    asan
    +authpolicy
    build_native_assistant
    +build_tests
    +chrome_debug
    +cfi
...

Shall I disable this to have a try?

Thanks
Yolanda

on comment 9, i should have said:

"I hope that the differences we are seeing are not related to USE="chrome_internal""

Yolanda, don't disable cfi. I believe there is no point in trying that since it is the default now. I just wanted to make sure you were doing your experiments with it enabled.

so, with the current linker script, everything seems to work for you?
Can you provide more details on what you are trying to do with the linker script?

Hi Yolanda, which version of Chrome are you currently working on?

on comment 9, i should have said:

"I hope that the differences we are seeing are not related to USE="chrome_internal""

Yolanda, don't disable cfi. I believe there is no point in trying that since it is the default now. I just wanted to make sure you were doing your experiments with it enabled.

so, with the current linker script, everything seems to work for you?
Can you provide more details on what you are trying to do with the linker script?

Hi, Yunlian

I am now using: 
ChromeOS: 11078.0.0
Chrome: 71.0.3554.0

We encountered the chrome runtime issue even without linkerscript.
The speedometer2.0 test cannot complete.

We just set USE="afdo_use lld -gold thinlto". All others are default.

Thanks
Yolanda

Hi Yolanda,
  Does the runtime issue happens without gold? If not, could you please file a bug
and put the information you have there?

Hi, Luis

The current linker script only works with LLD 8.0.0. With the prebuilt lld 7.0.0, I will still get the same linker error. The new linker script helps resolve some chrome load issue with the old one.

Yes, I did following experiments with linkerscript to test Speedometer2.0 performance.
1. With default field AFDO, the speedup is around 2.78%.
2. Add Speedometer2.0 profile to field AFDO, the speedup is around 5.67%. 
3. Based on 2 and combine C3, the speedup got to 9.0% 
We can share more details in our next sync meeting. :)

Thanks
Yolanda

Hi, Yunlian

The runtime issue happens with default lld 7.0.0 provided in chroot.
With gold it works fine. Shall I file a bug?

Hi Yolanda,
  Currently TOT chrome is using lld 8.0.0 now. If you still got the same error with that version, please file a bug.

  Thanks

Hi, Yunlian

Good to hear this. We will have a try soon!

Thanks
Yolanda

We upgrade LLD (along with LLVM and clang) in this CL
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1246304

Probably you can cherry pick this CL and run
./seutp_board --nousepkg inside chroot to update the toolchain

Thank you Yunlian for the tips！

I've been able to cherry pick this CL and resolved the conflicts. But when update the toolchain I encountered two issues:

1. Missing "~sys-devel/llvm-8.0_pre339409_p20180826":
emerge: there are no ebuilds to satisfy "~sys-devel/llvm-8.0_pre339409_p20180826[debug=,multitarget?,python?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]".
(dependency required by "sys-devel/clang-8.0_pre339409_p20180826-r1::chromiumos" [ebuild])

From the CL, it looks the correct ebuild name should be "*20180926.ebuild". Looks like a name typo?

Rename "clang-8.0_pre339409_p20180826-r1.ebuild" to "clang-8.0_pre339409_p20180926-r1.ebuild" seems work!

2. The update almost finished, but one more patch missing:
 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
llvm-8.0_pre339409_p20180926-r1:  * 
llvm-8.0_pre339409_p20180926-r1:  *   /mnt/host/source/src/third_party/chromiumos-overlay/sys-devel/llvm/files/cherry/b9c9629e618b883df7f03dc92f0d23eeca38693f.patch
llvm-8.0_pre339409_p20180926-r1:  *   ( b9c9629e618b883df7f03dc92f0d23eeca38693f.patch )


Caroline, do you know the details?

Thanks
Yolanda

Cherry picking following CLs are also needed to fix the build issue:

https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1249601
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1247762

Thank you for the new patches.

Unfortunately I still got problem missing below patch:

* Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
*  /mnt/host/source/src/third_party/chromiumos-overlay/sys-devel/llvm/files/cherry/b9c9629e618b883df7f03dc92f0d23eeca38693f.patch
*   ( b9c9629e618b883df7f03dc92f0d23eeca38693f.patch )

Any tip where I can find this patch file?
/mnt/host/source/src/third_party/chromiumos-overlay/sys-devel/llvm/files/cherry/b9c9629e618b883df7f03dc92f0d23eeca38693f.patch

It seems required from "llvm-8.0_pre339409_p20180926-r1.ebuild":
        # llvm
        CHERRIES=""
        CHERRIES+=" 3e5777f3b95e846530d70ed76577abca1be4f5f5" # r339411
        CHERRIES+=" 77a17afc92d543811e0f4f7913d4424aa630c117" # r340610
        CHERRIES+=" ddf089299bbfec8b94a61ffd83b2360e061dc108" # r340642
        CHERRIES+=" a4da437c1dec3fec9cf24e5d4b40bc77c2a6cec2" # r340654
        CHERRIES+=" b9c9629e618b883df7f03dc92f0d23eeca38693f" # r341512
        CHERRIES+=" 42eb082d63383b17c395e033e0095076efe4cb5e" # r341593
        CHERRIES+=" 906fd9ab476d0fa9e221bec32009eac3f3af5c60" # r341706
...


Thanks
Yolanda

I can find the patch files from master branch.
I will continue to update the toolchain see if it works this time. :)

I finally upgraded the toolchain successfully with below cherry picks:

https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1246304
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1249601
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1247762
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1246277

In addition, I also did below workarounds:
1. Copy "chromiumos-overlay/sys-devel/llvm/files/cherry/b9c9629e618b883df7f03dc92f0d23eeca38693f.patch" from master
2. Also dropped "armv7a-cros-linux-gnueabihf", "aarch64-cros-linux-gnu" support for rust following CL 1246277 in:
chromiumos-overlay/dev-lang/rust/rust-1.29.0-r1.ebuild
Otherwise I will encounter missing armv7a-cros-linux-gnueabihf-clang error.
This seems unnecessary to build reef.

The build now passed successfully with or w/o linkerscript!
My use setting: USE="afdo_use lld -gold"

We will evaluate the image and see if it will run correctly.

The reef image can load successfully on electro. I will check Speedometer2.0 score tomorrow.

Unfortunately we still encountered the Speedometer2.0 crash issue with the new image, even though the build with linkerscript can complete successfully now with 8.0.0 toolchain.

I will try upgrade my ChromeOS version, also latest LLVM, see any difference.

thanks for the update. 

I forgot to mention in the meeting that we are still trying to figure out the bug with LLD (crash when loging). Because of this we have nto been able to move from Gold to LLD. 

Hi, Luis

By simply replacing the upgraded lld to my local lld 8.0.0, the image works correctly. So seems the problem only relates to the new lld.

I checked the last commit from my local lld. It is up to Sept 18:
commit 9b7710b45abec273f5e66515f2dafeadeee444fd
Author: Martin Storsjo <martin@martin.st>
Date:   Tue Sep 18 07:22:05 2018 +0000

    [COFF] Fix the name mangling of a function in the autoexport exclusion list

    The __NULL_IMPORT_DESCRIPTOR symbol has two leading underscores on
    architectures other than i386 as well; it is not a mangled symbol name.

    git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@342448 91177308-0d34-0410-b5e6-96231b3b80d8


While the upstream lld from "sys-devel/lld-8.0_pre339409-r1" seems based on  older commit on Aug 9:

commit e260fac81cb305498a823b059ba8279b520296cc
Author: Sid Manning <sidneym@codeaurora.org>
Date:   Thu Aug 9 20:04:53 2018 +0000

    [ELF][HEXAGON] Add R_HEX_HI16/R_HEX_LO16 relocations

    Differential Revision: https://reviews.llvm.org/D50520

    git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@339371 91177308-0d34-0410-b5e6-96231b3b80d8

There's one more cherry fc72aa for Aug 28 however it's still possible there're more fixes in between that may be able to resolve the bug.

Also here's my llvm head log. They must be consistent with lld's head otherwise may encounter unresolved symbol errors:
commit b74b9fdb9a238c948f7d043b3004e6ce61ad1cda
Author: Thomas Lively <tlively@google.com>
Date:   Wed Sep 19 00:54:20 2018 +0000

    [WebAssembly][NFC] Remove extra space in WebAssemblyInstrSIMD.td

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@342522 91177308-0d34-0410-b5e6-96231b3b80d8

Hope this can provide some clue in resolving the bug.

Thanks Yolanda, 

Caroline is trying with latest LLD and LLVM.