On Wed, Aug 28, 2024 at 12:07 AM Anthonin Bonnefoy <anthonin.bonne...@datadoghq.com> wrote: > On Tue, Aug 27, 2024 at 12:01 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > Thanks! And that's great news. Do you want to report this experience > > to the PR, in support of committing it? That'd make it seem easier to > > consider shipping a back-ported copy... > > Yes, I will do that.
Thanks. Here's a slightly tidied up version: 1. I used namespace llvm::backport, instead of a different class name. That minimises the diff against their code. 2. I tested against LLVM 10-18, and found that 10 and 11 lack some needed symbols. So I just hid this code from them. Even though our stable branches support those and even older versions, I am not sure if it's worth trying to do something about that for EOL'd distros that no one has ever complained about. I am willing to try harder if someone thinks that's important... One little problem I am aware of is that if you make an empty .o, macOS's new linker issues a warning, but I think I could live with that. I guess I could put a dummy symbol in there... FWIW those old LLVM versions spit out tons of other warnings from the headers on newer compilers too, so *shrug*, don't use them? But then if this code lands in LLVM 19 we'll also be hiding it for 19+ too. Next, I think we should wait to see if the LLVM project commits that PR, this so that we can sync with their 19.x stable branch, instead of using code from a PR. Our next minor release is in November, so we have some time. If they don't commit it, we can consider it anyway: I mean, it's crashing all over the place in production, and we see that other projects are shipping this code already.
v4-0001-Backport-of-LLVM-code-to-fix-ARM-relocation-bug.patch
Description: Binary data
