ObjWriter: Do not generate relocations within .debug_info for DW_AT_type #98597
Conversation
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsFixes #98377. Neither gcc, nor clang, generate relocations for references within the same
|
filipnavara
added
the
community-contribution
|
Tested with your branch, still getting the warning (with smaller offsets): |
|
Damn. I wonder what’s wrong with the linker. I guess I will have to reproduce the whole flow locally. |
|
@am11 Could you please share the |
|
I run it through So, either I messed something up or it didn't use the new ILCompiler. |
|
Ah, I see, I missed one place: |
|
I updated the PR. A retest would be nice. Thanks for bearing with me on this one! |
|
All good! 👍 The flow I'm using is a bit involved (and most likely inefficient). I am testing on macOS, with #98603, the "live" hello world app built via sdk. Can do the same with some simple smoke test binary as well, haven't tried. 😅 nine.tar.gz (this is helloworld + custom nuget.config) # host osx-arm64
$ git clone https://github.com/dotnet/runtime --single-branch --depth 1; cd runtime
$ curl -sSL https://github.com/dotnet/runtime/pull/98603.patch | git apply -
$ curl -sSL https://github.com/dotnet/runtime/pull/98597.patch | git apply -
$ curl -sSLO https://github.com/dotnet/runtime/files/14319205/nine.tar.gz
$ docker run --rm -v$(pwd):/runtime -w /runtime \
--platform linux/arm64 -it alpine
# in container REPL
$ eng/install-native-dependencies.sh
$ tar xzf nine.tar.gz -C /
# repeatable
$ rm -rf artifacts
$ ./build.sh clr+libs+packs
$ /runtime/dotnet.sh nuget locals all --clear
$ cd /nine
$ rm -rf obj bin dist packs1
$ /runtime/dotnet.sh publish -p:PublishAot=true -o dist -p:StripSymbols=false --packages packs1
$ apk add binutils
$ nm --portability --line-numbers dist/nine > /dev/null
# this time no warnings! 🎉 |
|
Thanks for checking!
Yeah, I figured that's what you are likely doing. I tried numerous different ways:
|
|
That is unfortunate. Even this docker flow sometimes fail in packs subset, but right after clreaing ILCompiler nupkg which we are interested in 😅 I guess this intermittent failure is some hardlink issue of msbuild (or the way our sfxprojs are authored?). Luckily we can continue testing ilcompiler nupkg even with this broken flow. :) |
It could also be an issue with the filesystem sync of the mounted volume from the mac host, you might want to try cloning the runtime repo inside of the docker linux filesystem. |
I noticed that when it fails, it seems to be always failing on |
$ ./build.sh packs -c Release -v:diag
...
11:50:00.347 7:3>/runtime/.dotnet/sdk/9.0.100-alpha.1.23615.4/Sdks/NuGet.Build.Tasks.Pack/build/NuGet.Build.Tasks.Pack.targets(221,5): error : Could not find a part of the path '/runtime/src/installer/pkg/sfx/Microsoft.NETCore.App'. [/runtime/
src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Ref.sfxproj]
Assembly loaded during TaskRun (NuGet.Build.Tasks.Pack.PackTask): System.Diagnostics.StackTrace, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (location: /runtime/.dotnet/shared/Microsoft.NETCore.App/9.0.
0-alpha.1.23614.10/System.Diagnostics.StackTrace.dll, MVID: e4055d45-a175-49e1-afcb-8df2f6d2eee3, AssemblyLoadContext: Default) (TaskId:14)
System.IO.DirectoryNotFoundException: Could not find a part of the path '/runtime/src/installer/pkg/sfx/Microsoft.NETCore.App'.
at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
at System.IO.Enumeration.FileSystemEnumerator`1.Init()
at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
at System.IO.Enumeration.FileSystemEnumerableFactory.UserFiles(String directory, String expression, EnumerationOptions options)
at System.IO.Directory.InternalEnumeratePaths(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
at System.IO.Directory.GetFiles(String path, String searchPattern, EnumerationOptions enumerationOptions)
at NuGet.Common.PathResolver.PerformWildcardSearch(String basePath, String searchPath, Boolean includeEmptyDirectories, String& normalizedBasePath)
at NuGet.Packaging.PackageBuilder.ResolveSearchPattern(String basePath, String searchPath, String targetPath, Boolean includeEmptyDirectories)
at NuGet.Packaging.PackageBuilder.AddFiles(String basePath, String source, String destination, String exclude)
at NuGet.Packaging.PackageBuilder.PopulateFiles(String basePath, IEnumerable`1 files)
at NuGet.Commands.MSBuildProjectFactory.CreateBuilder(String basePath, NuGetVersion version, String suffix, Boolean buildIfNeeded, PackageBuilder builder)
at NuGet.Commands.PackCommandRunner.BuildFromProjectFile(String path)
at NuGet.Build.Tasks.Pack.PackTask.Execute() (TaskId:14)
Done executing task "PackTask" -- FAILED. (TaskId:14)the directory exists: $ ls /runtime/src/installer/pkg/sfx/Microsoft.NETCore.App
Directory.Build.props Microsoft.NETCore.App.Host.sfxproj Microsoft.NETCore.App.MonoCrossAOT.sfxproj Microsoft.NETCore.App.Runtime.sfxproj monocrossaot.sfxproj
Directory.Build.targets Microsoft.NETCore.App.MonoCrossAOT.Sdk.props.in Microsoft.NETCore.App.Ref.sfxproj PackageOverrides.txt
Microsoft.NETCore.App.Crossgen2.sfxproj Microsoft.NETCore.App.MonoCrossAOT.UnixFilePermissions.xml.in Microsoft.NETCore.App.Runtime.props ReadyToRun.targetWith this code (based on https://github.com/NuGet/NuGet.Client/blob/61bd0d260ea2f849dd842e1a881e99b875b085f4/src/NuGet.Core/NuGet.Common/PathUtil/PathResolver.cs#L149): using System;
using System.IO;
const string path = "/runtime/src/installer/pkg/sfx/Microsoft.NETCore.App";
foreach (string file in System.IO.Directory.GetFiles(path, "*", SearchOption.TopDirectoryOnly).AsParallel())
{
Console.WriteLine(file);
}
foreach (string file in System.IO.Directory.GetFiles(path, "*", SearchOption.AllDirectories).AsParallel())
{
Console.WriteLine(file);
}it lists all the files (in release and debug). No idea where the mix up is happening. 🤷♂️ |
|
@am11 this is pretty weird, the |
|
Looks like VirtioFS instability issue docker/for-mac#6219 (comment)
still no idea why it fails only at that particular sfxproj (after building/packing hundreds of projects and compiling loads of native code on that mount) i'll now stop hijacking @filipnavara's thread. 😁 |
Fixes #98377.
Neither gcc, nor clang, generate relocations for references within the same
.debug_infosection. The DWARF 5 specification, section 7.3.1, doesn't list this type of relocation as required. At least some versions of GNU binutils linker seem to apply both the relocation and their own offset in the final file, resulting in the offset being applied twice.