I broke lit on exotic architectures, what can I do?

I submitted a change that avoids using os.path.realpath in lit.py: ⚙ D152709 [lit] Avoid os.path.realpath in lit.py due to MAX_PATH limitations on Windows . This passed all tests locally but broke on Buildbot: builder clang-m68k-linux-cross build 2519 (llvm.org) and Buildbot: builder clang-ppc64-aix build 7990 (llvm.org).

In both cases it seems due to symlinks used on the build machines configurations (/srv/var/lib and /scratch/home) and a comparison between paths where symlinks are expanded and paths where they are not.

I suspect it has to do with the remaining os.path.realpath in llvm-project/llvm/utils/llvm-lit/llvm-lit.in at main · llvm/llvm-project · GitHub, but I have no way to verify it. Should I just blindly submit a new patch? How else can I investigate this?

Maybe disable MAX_PATH limitation in the Windows registry and revert the patch?

That is not a solution that scales. Not all environments can make the registry change for that. I think that the fix to lit to deal with the fact that python changed behaviour across versions is the correct thing.

I believe that they are looking for a way to reproduce the error so that they can fix the issue.

Sounds like the answer is “build LLVM with the source and/or build directory on a symlinked path”?

I did this and could not repro the failure. This was on a Windows machine, so I’m trying to setup a Linux machine and run the build & tests again.

  1. If you haven’t already, make sure to revert your patch that broke things. You should avoid leaving build bots in a broken state for any significant amount of time.
  2. It’s quite possible that you won’t be able to recreate a buildbot’s environment. For example, I doubt that you’ve got a PowerPC architecture with AIX OS installed on it kicking around. Assuming you don’t and you can’t figure out what’s wrong just by reading the reports and the code, you will need to reach out to build bot owners, or others who have access to these configs in order to investigate the issue and try out a fix.

That being said, if you’re somewhat confident that a potential change will fix the issue, there’s nothing wrong in committing the fix. However, you shouldn’t do this blindly if you think there’s a reasonable chance it will make things worse.

1 Like

I submitted a likely fix: :gear: D153125 [lit] Likely fix for symlink path failures after D152709 (llvm.org)

Now reverting in :gear: D153138 [lit] Revert migration from os.path.realpath to os.path.abspath (llvm.org)