[gem5-users] Re: Compiling gem5 on ARM Based Host
As far as why opt is smaller than fast, that could be because the compiler is optimizing more aggressively for performance at the cost of binary size with those settings? Just a guess. Gabe On Fri, Jan 7, 2022 at 10:45 AM Thomas, Samuel via gem5-users < gem5-users@gem5.org> wrote: > Hi Jason, > > Weirdly, only a few fast binaries exceed 5MB in size: > > 5.6Mbuild/ARM/arch/arm/generated/generic_cpu_exec_2.fo > 6.0Mbuild/ARM/arch/arm/generated/generic_cpu_exec_5.fo > 6.0Mbuild/ARM/arch/arm/generated/inst-constrs-1.fo > 6.1Mbuild/ARM/arch/arm/generated/generic_cpu_exec_4.fo > 6.8Mbuild/ARM/arch/arm/generated/generic_cpu_exec_3.fo > 8.0Mbuild/ARM/arch/arm/generated/inst-constrs-2.fo > 9.5Mbuild/ARM/arch/arm/linux/se_workload.fo > 15M build/ARM/arch/arm/generated/generic_cpu_exec_1.fo > 16M build/ARM/arch/arm/generated/generic_cpu_exec_6.fo > 45M build/ARM/arch/arm/generated/inst-constrs-3.fo > > Perhaps even weirder is that the “opt” target compiles and links > correctly. Could you speculate as to why this may be the case? > > At least for the purposes of my project, I can use gem5.opt - so my issue > is resolved even if the larger problem is still open. Thanks for your help! > > Best, > Sam > > On Fri, Jan 7, 2022 at 12:57 PM Jason Lowe-Power > wrote: > > > > Hi Sam, > > > > I was wondering when this problem would come up again. Here's a Jira > issue to track the same thing in a different context: > https://gem5.atlassian.net/browse/GEM5-1003 > > > > Could you do something like `du -h build/ | sort -h` to see what objects > are the biggest? I'm going to guess that there are ~100+ .o files that are > more than 20MB. At least, that was the case with RISC-V when I ran into > this problem. > > > > We never did figure out why so many files were so big. The hypothesis > was something to do with pybind, but no one was able to provide solid > evidence of this. We did find that using a different compiler version, > having different libraries installed on the system, and removing > unnecessary includes seemed to make a difference, though. You may be able > to use this to at least work around the problem. > > > > Here's the changeset that fixed it for RISC-V. However, I doubt it's > going to fix it again in your case. > https://gem5-review.googlesource.com/c/public/gem5/+/46820 > > > > You can also try this abandoned change, though it probably won't apply > cleanly or straightforwardly: > https://gem5-review.googlesource.com/c/public/gem5/+/46380 > > > > Cheers, > > Jason > > > > On Fri, Jan 7, 2022 at 9:39 AM Samuel Thomas via gem5-users < > gem5-users@gem5.org> wrote: > >> > >> Hi all, > >> > >> I typically work on an x86 machine, but I’m trying to submit gem5 jobs > to a cluster that runs ARM based hosts. Each source script compiles, I run > into the following error when linking: > >> > >> /tmp/gem5.fast.unstripped.PI0JsN.ltrans45.ltrans.o: in function > `ArmV8KvmCPU::updateThreadContext()': > >> :(.text+0x25884): relocation truncated to fit: > R_AARCH64_ADR_PREL_PG_HI21 against `.rodata’collect2: error: ld returned 1 > exit status > >> > >> It makes sense that the .text segment of the binary will be very large, > and I see that there is a note on gem5’s architecture support documentation > that it is out dated. I assume that I can try disassembling the binary and > seeing if there is an alternative command to avoid this particular linker > error, but I figured I would also ping the mailing list to see if there is > an easier fix as well. > >> > >> Thank you all for your help! > >> > >> Best, > >> Sam > >> ___ > >> gem5-users mailing list -- gem5-users@gem5.org > >> To unsubscribe send an email to gem5-users-le...@gem5.org > >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: Compiling gem5 on ARM Based Host
Hi Jason, Weirdly, only a few fast binaries exceed 5MB in size: 5.6Mbuild/ARM/arch/arm/generated/generic_cpu_exec_2.fo 6.0Mbuild/ARM/arch/arm/generated/generic_cpu_exec_5.fo 6.0Mbuild/ARM/arch/arm/generated/inst-constrs-1.fo 6.1Mbuild/ARM/arch/arm/generated/generic_cpu_exec_4.fo 6.8Mbuild/ARM/arch/arm/generated/generic_cpu_exec_3.fo 8.0Mbuild/ARM/arch/arm/generated/inst-constrs-2.fo 9.5Mbuild/ARM/arch/arm/linux/se_workload.fo 15M build/ARM/arch/arm/generated/generic_cpu_exec_1.fo 16M build/ARM/arch/arm/generated/generic_cpu_exec_6.fo 45M build/ARM/arch/arm/generated/inst-constrs-3.fo Perhaps even weirder is that the “opt” target compiles and links correctly. Could you speculate as to why this may be the case? At least for the purposes of my project, I can use gem5.opt - so my issue is resolved even if the larger problem is still open. Thanks for your help! Best, Sam On Fri, Jan 7, 2022 at 12:57 PM Jason Lowe-Power wrote: > > Hi Sam, > > I was wondering when this problem would come up again. Here's a Jira issue to > track the same thing in a different context: > https://gem5.atlassian.net/browse/GEM5-1003 > > Could you do something like `du -h build/ | sort -h` to see what objects are > the biggest? I'm going to guess that there are ~100+ .o files that are more > than 20MB. At least, that was the case with RISC-V when I ran into this > problem. > > We never did figure out why so many files were so big. The hypothesis was > something to do with pybind, but no one was able to provide solid evidence of > this. We did find that using a different compiler version, having different > libraries installed on the system, and removing unnecessary includes seemed > to make a difference, though. You may be able to use this to at least work > around the problem. > > Here's the changeset that fixed it for RISC-V. However, I doubt it's going to > fix it again in your case. > https://gem5-review.googlesource.com/c/public/gem5/+/46820 > > You can also try this abandoned change, though it probably won't apply > cleanly or straightforwardly: > https://gem5-review.googlesource.com/c/public/gem5/+/46380 > > Cheers, > Jason > > On Fri, Jan 7, 2022 at 9:39 AM Samuel Thomas via gem5-users > wrote: >> >> Hi all, >> >> I typically work on an x86 machine, but I’m trying to submit gem5 jobs to a >> cluster that runs ARM based hosts. Each source script compiles, I run into >> the following error when linking: >> >> /tmp/gem5.fast.unstripped.PI0JsN.ltrans45.ltrans.o: in function >> `ArmV8KvmCPU::updateThreadContext()': >> :(.text+0x25884): relocation truncated to fit: >> R_AARCH64_ADR_PREL_PG_HI21 against `.rodata’collect2: error: ld returned 1 >> exit status >> >> It makes sense that the .text segment of the binary will be very large, and >> I see that there is a note on gem5’s architecture support documentation that >> it is out dated. I assume that I can try disassembling the binary and seeing >> if there is an alternative command to avoid this particular linker error, >> but I figured I would also ping the mailing list to see if there is an >> easier fix as well. >> >> Thank you all for your help! >> >> Best, >> Sam >> ___ >> gem5-users mailing list -- gem5-users@gem5.org >> To unsubscribe send an email to gem5-users-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-users] Re: Compiling gem5 on ARM Based Host
Hi Sam, I was wondering when this problem would come up again. Here's a Jira issue to track the same thing in a different context: https://gem5.atlassian.net/browse/GEM5-1003 Could you do something like `du -h build/ | sort -h` to see what objects are the biggest? I'm going to guess that there are ~100+ .o files that are more than 20MB. At least, that was the case with RISC-V when I ran into this problem. We never did figure out why so many files were so big. The hypothesis was something to do with pybind, but no one was able to provide solid evidence of this. We did find that using a different compiler version, having different libraries installed on the system, and removing unnecessary includes seemed to make a difference, though. You may be able to use this to at least work around the problem. Here's the changeset that fixed it for RISC-V. However, I doubt it's going to fix it again in your case. https://gem5-review.googlesource.com/c/public/gem5/+/46820 You can also try this abandoned change, though it probably won't apply cleanly or straightforwardly: https://gem5-review.googlesource.com/c/public/gem5/+/46380 Cheers, Jason On Fri, Jan 7, 2022 at 9:39 AM Samuel Thomas via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > I typically work on an x86 machine, but I’m trying to submit gem5 jobs to > a cluster that runs ARM based hosts. Each source script compiles, I run > into the following error when linking: > > /tmp/gem5.fast.unstripped.PI0JsN.ltrans45.ltrans.o: in function > `ArmV8KvmCPU::updateThreadContext()': > :(.text+0x25884): relocation truncated to fit: > R_AARCH64_ADR_PREL_PG_HI21 against `.rodata’collect2: error: ld returned 1 > exit status > > It makes sense that the .text segment of the binary will be very large, > and I see that there is a note on gem5’s architecture support documentation > that it is out dated. I assume that I can try disassembling the binary and > seeing if there is an alternative command to avoid this particular linker > error, but I figured I would also ping the mailing list to see if there is > an easier fix as well. > > Thank you all for your help! > > Best, > Sam > ___ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
