Add linux x86 build CI for pull request by clamp03 · Pull Request #60817 · dotnet/runtime

clamp03 · 2021-10-25T00:30:13Z

No description provided.

ghost · 2021-10-25T00:30:17Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

jkotas · 2021-10-25T02:42:29Z

Looks like the current changes are breaking dotnet-runtime pipeline. Nothing from the pipeline run.

clamp03 · 2021-10-26T02:33:52Z

@jkotas @safern Could you please review again? I fixed some mistakes in the first commit and some build errors. I think CI failures are not caused by this PR.

@alpencolt @gbalykov It builds linux x86 with src/coreclr/build-runtime.sh checked x86 -cross -ci -clang9 -component runtime -component jit -component iltools and build.sh -subset clr.corelib -cross -arch x86 -c checked -ci commands. These builds only possible components for normal Linux x86 build . Please check these are good for our tizen build.
cc @wscho77 @HJLeee

jkotas · 2021-10-26T02:51:08Z

The windows x86 legs are failing with unique errors. They may be related to this change somehow.

gbalykov · 2021-10-26T08:28:06Z

@clamp03 last time I checked (#50836 and 6.0-preview7), linux x86 build worked for next subsets: clr.runtime+clr.corelib+clr.iltools+clr.dactools+clr.jit, i.e.

ROOTFS_DIR=`pwd`/.tools/rootfs/x86/ ./build.sh --cross --arch x86 --runtimeConfiguration Release --librariesConfiguration Release --subset clr.runtime+clr.corelib+clr.iltools+clr.dactools+clr.jit

Has something changed?

gbalykov

Ah, I see that CI uses build-runtime.sh script directly for runtime build instead of build.sh. Looks good.

clamp03 · 2021-10-27T01:27:46Z

@gbalykov Thank you for the review.
@jkotas @safern Fixed an issue. All checks are passed. Could you please review it?
Thank you.

safern

Pipeline changes LGTM.

clamp03 · 2021-10-28T07:57:17Z

@safern Thank you!
@jkotas Fixed a conflict. Could you please review and merge if it is correct?

jkotas · 2021-10-28T17:57:55Z

What is this change trying to fix?

@VSadov Could you please review this line?

I am not sure I follow why this might be needed, on x86 specifically.

Normally we use it to avoid clash between two instances of gcdecode.cpp which both JIT and VM include, so when they are both statically linked into singlefile host, we need to pick just one.
And dac, I think needs gcdecode.cpp regardless of singlefile.

What is different on x86?

@hoyosjs - does dac need gcdecode.cpp on x86 ?

~~If it's used by the VM, most likely yes~~. The decoder only gets used in x86 looks like, and yeah - verified and there's calls to the functions in the decoder. SOS also uses a copy of it heavily.

Build error message which I try to fix is

>> gcdump_dac.cpp.o:(.text+0x1D0) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: decodeSigned(__ArrayDPtr<unsigned char const>, int*) >>> defined at gcdecoder.cpp:64 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:64) >>> gcdecode.cpp.o:(decodeSigned(__ArrayDPtr<unsigned char const>, int*)) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:64 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:64) >>> gcdump_dac.cpp.o:(.text+0x130) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: decodeUDelta(__ArrayDPtr<unsigned char const>, unsigned int*, unsigned int) >>> defined at gcdecoder.cpp:51 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:51) >>> gcdecode.cpp.o:(decodeUDelta(__ArrayDPtr<unsigned char const>, unsigned int*, unsigned int)) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:51 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:51) >>> gcdump_dac.cpp.o:(.text+0xA0) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: decodeUnsigned(__ArrayDPtr<unsigned char const>, unsigned int*) >>> defined at gcdecoder.cpp:34 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:34) >>> gcdecode.cpp.o:(decodeUnsigned(__ArrayDPtr<unsigned char const>, unsigned int*)) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:34 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:34) >>> gcdump_dac.cpp.o:(.text+0x0) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: decodeCallPattern(int, unsigned int*, unsigned int*, unsigned int*, unsigned int*) >>> defined at gcdecoder.cpp:261 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:261) >>> gcdecode.cpp.o:(decodeCallPattern(int, unsigned int*, unsigned int*, unsigned int*, unsigned int*)) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:261 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:261) >>> gcdump_dac.cpp.o:(.text+0x670) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: InfoHdrSmall::isHeaderMatch(InfoHdr const&) const >>> defined at gcdecoder.cpp:466 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:466) >>> gcdecode.cpp.o:(InfoHdrSmall::isHeaderMatch(InfoHdr const&) const) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:466 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:466) >>> gcdump_dac.cpp.o:(.text+0x6B0) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: callCommonDelta >>> defined at gcdecoder.cpp:505 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:505) >>> gcdecode.cpp.o:(callCommonDelta) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:505 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:505) >>> gcdump_dac.cpp.o:(.rodata+0xB20) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: callPatternTable >>> defined at gcdecoder.cpp:534 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:534) >>> gcdecode.cpp.o:(callPatternTable) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:534 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:534) >>> gcdump_dac.cpp.o:(.rodata+0xB30) in archive ../../debug/daccess/libdaccess.a ld.lld: error: duplicate symbol: infoHdrShortcut >>> defined at gcdecoder.cpp:279 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:279) >>> gcdecode.cpp.o:(infoHdrShortcut) in archive ../../vm/libcee_dac.a >>> defined at gcdecoder.cpp:279 (/dotnet/jobs/ci/check/src/coreclr/inc/gcdecoder.cpp:279) >>> gcdump_dac.cpp.o:(.rodata+0x1A0) in archive ../../debug/daccess/libdaccess.a clang: error: linker command failed with exit code 1 (use -v to see invocation) dlls/mscordac/CMakeFiles/mscordaccore.dir/build.make:147: recipe for target 'dlls/mscordac/libmscordaccore.so' failed make[3]: *** [dlls/mscordac/libmscordaccore.so] Error 1 CMakeFiles/Makefile2:4161: recipe for target 'dlls/mscordac/CMakeFiles/mscordaccore.dir/all' failed make[2]: *** [dlls/mscordac/CMakeFiles/mscordaccore.dir/all] Error 2

For libmscordaccore build, cee_dac and daccess conflict by including same src/coreclr/inc/gcdecorder.cpp
I thought gcdecoder.cpp can be excluded because it is already included in daccess.

@VSadov I checked Include vm/gcdecode.cpp in only windows (exclude vm/gcdecode.cpp from linux-x86). Simple tests work in linux-x86.

I think that cee_dac doesn't need to include inc/gcdecoder.cpp in windows. I guess a compiler of windows can resolve this duplicated symbols well. Actually, with clang10 (and above), it compiles without the duplicated symbol errors in linux. (*. CI uses clang9)

@clamp03 - yes on Windows compiler could be more tolerant to symbol duplication.
Did you get errors when you tried the change in 4147fb6 ?

I didn't get any errors. Reverted the last commit. Now it includes gcdecode.cpp in only windows. Thank you!

This reverts commit 65e59345f1b9e8d331cdbb695d92c52cff657bd5.

clamp03 · 2021-11-02T04:19:20Z

@jkotas @VSadov Could you please review again and then merge if it is good? Thank you.

jkotas

LGTM. Thanks!

ghost added the community-contribution Indicates that the PR has been added by a community member label Oct 25, 2021

clamp03 force-pushed the linux-x86 branch from 48bc0d3 to 2ae706b Compare October 25, 2021 00:33

clamp03 mentioned this pull request Oct 25, 2021

[Tizen ] X86 Linux CI for pull requests #60452

Closed

jkotas added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Oct 25, 2021

clamp03 force-pushed the linux-x86 branch 3 times, most recently from a52cf63 to c08b276 Compare October 25, 2021 13:05

runfoapp Bot mentioned this pull request Oct 25, 2021

1ES Pools often run out of space #60610

Closed

clamp03 force-pushed the linux-x86 branch from c08b276 to 7bbc612 Compare October 25, 2021 23:39

clamp03 commented Oct 26, 2021

View reviewed changes

Comment thread src/coreclr/vm/CMakeLists.txt Resolved

clamp03 force-pushed the linux-x86 branch from 9e0926c to f69be24 Compare October 26, 2021 05:22

gbalykov approved these changes Oct 26, 2021

View reviewed changes

runfoapp Bot mentioned this pull request Oct 26, 2021

profiler.elt work item test failures in slowpatheltenter #60018

Closed

safern approved these changes Oct 27, 2021

View reviewed changes

clamp03 force-pushed the linux-x86 branch 2 times, most recently from 1aeb75e to 2c0aa64 Compare October 28, 2021 05:53

jkotas reviewed Oct 28, 2021

View reviewed changes

clamp03 force-pushed the linux-x86 branch from 2c0aa64 to d1b8d10 Compare November 2, 2021 00:01

clamp03 added 5 commits November 2, 2021 11:01

Add linux x86 build CI for pull request

6288111

Fix some mistakes

38f863c

Fix linux x86 build error

8023fef

Fix linux x86 linking error

8069635

Fix a mistake

9d613e2

clamp03 added 3 commits November 2, 2021 11:01

Include gcdecode.cpp in only windows x86

1ccfaa8

Fix error in another way

99e99b7

Revert "Fix error in another way"

5693c0b

This reverts commit 65e59345f1b9e8d331cdbb695d92c52cff657bd5.

clamp03 force-pushed the linux-x86 branch from d1b8d10 to 5693c0b Compare November 2, 2021 02:02

jkotas approved these changes Nov 2, 2021

View reviewed changes

jkotas merged commit bfcb542 into dotnet:main Nov 2, 2021

clamp03 deleted the linux-x86 branch November 2, 2021 04:34

ghost locked as resolved and limited conversation to collaborators Dec 2, 2021

Conversation

clamp03 commented Oct 25, 2021

Uh oh!

ghost commented Oct 25, 2021

Uh oh!

jkotas commented Oct 25, 2021

Uh oh!

clamp03 commented Oct 26, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jkotas commented Oct 26, 2021

Uh oh!

Uh oh!

gbalykov commented Oct 26, 2021

Uh oh!

gbalykov left a comment

Choose a reason for hiding this comment

Uh oh!

clamp03 commented Oct 27, 2021

Uh oh!

safern left a comment

Choose a reason for hiding this comment

Uh oh!

clamp03 commented Oct 28, 2021

Uh oh!

jkotas Oct 28, 2021

Choose a reason for hiding this comment

Uh oh!

VSadov Oct 28, 2021

Choose a reason for hiding this comment

Uh oh!

VSadov Oct 28, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov Oct 28, 2021

Choose a reason for hiding this comment

Uh oh!

hoyosjs Oct 28, 2021

Choose a reason for hiding this comment

Uh oh!

clamp03 Oct 29, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clamp03 Oct 29, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clamp03 Oct 29, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov Nov 1, 2021

Choose a reason for hiding this comment

Uh oh!

clamp03 Nov 2, 2021

Choose a reason for hiding this comment

Uh oh!

clamp03 commented Nov 2, 2021

Uh oh!

jkotas left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

clamp03 commented Oct 26, 2021 •

edited

Loading

VSadov Oct 28, 2021 •

edited

Loading

clamp03 Oct 29, 2021 •

edited

Loading

clamp03 Oct 29, 2021 •

edited

Loading

clamp03 Oct 29, 2021 •

edited

Loading