[llvm-branch-commits] [llvm] release/21.x: [BPF] Backport backend fixes related to BTF (PR #165154)

2025-10-26 Thread Michal R via llvm-branch-commits

https://github.com/vadorovsky edited 
https://github.com/llvm/llvm-project/pull/165154
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/21.x: [BPF] Backport backend fixes related to BTF (PR #165154)

2025-10-26 Thread Michal R via llvm-branch-commits

https://github.com/vadorovsky edited 
https://github.com/llvm/llvm-project/pull/165154
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/21.x: Backport BPF backend fixes (PR #165154)

2025-10-26 Thread Michal R via llvm-branch-commits

https://github.com/vadorovsky created 
https://github.com/llvm/llvm-project/pull/165154

Backport the following commits to 21.x branch, that fix the BTF debug info 
generation for IR produced by Rust frontend:

* 7ae7a5ad51f32118161ee0aaa13b11368aa5d29b
* ad582e383369fc32fffb016be68b1ba7812f2325 - this one is especially important, 
without it Rust is capable of causing assertion failures (#155778)

>From 91c5f2538e9ec361ae4e300f77e080f81ab31d56 Mon Sep 17 00:00:00 2001
From: Michal R 
Date: Mon, 20 Oct 2025 20:07:55 +0200
Subject: [PATCH 1/2] [BPF] Support for `DW_TAG_variant_part` in BTF generation
  (#155783)

Variant part, represented by `DW_TAG_variant_part` is a structure with a
discriminant and different variants, from which only one can be active
and valid at the same time. The discriminant is the main difference
between variant parts and unions represented by `DW_TAG_union` type.

Variant parts are used by Rust enums, which look like:

```rust
pub enum MyEnum {
First { a: u32, b: i32 },
Second(u32),
}
```

This type's debug info is the following `DICompositeType` with
`DW_TAG_structure_type` tag:

```llvm
!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyEnum",
 scope: !2, file: !5, size: 96, align: 32, flags: DIFlagPublic,
 elements: !6, templateParams: !16,
 identifier: "faba668fd9f71e9b7cf3b9ac5e8b93cb")
```

With one element being also a `DICompositeType`, but with
`DW_TAG_variant_part` tag:

```llvm
!6 = !{!7}
!7 = !DICompositeType(tag: DW_TAG_variant_part, scope: !4, file: !5,
 size: 96, align: 32, elements: !8, templateParams: !16,
 identifier: "e4aee046fc86d111657622fdcb8c42f7", discriminator: !21)
```

Which has a discriminator:

```llvm
!21 = !DIDerivedType(tag: DW_TAG_member, scope: !4, file: !5,
  baseType: !13, size: 32, align: 32, flags: DIFlagArtificial)
```

Which then holds different variants as `DIDerivedType` elements with
`DW_TAG_member` tag:

```llvm
!8 = !{!9, !17}
!9 = !DIDerivedType(tag: DW_TAG_member, name: "First", scope: !7,
 file: !5, baseType: !10, size: 96, align: 32, extraData: i32 0)
!10 = !DICompositeType(tag: DW_TAG_structure_type, name: "First",
  scope: !4, file: !5, size: 96, align: 32, flags: DIFlagPublic,
  elements: !11, templateParams: !16,
  identifier: "cc7748c842e275452db4205b190c8ff7")
!11 = !{!12, !14}
!12 = !DIDerivedType(tag: DW_TAG_member, name: "a", scope: !10,
  file: !5, baseType: !13, size: 32, align: 32, offset: 32,
  flags: DIFlagPublic)
!13 = !DIBasicType(name: "u32", size: 32, encoding: DW_ATE_unsigned)
!14 = !DIDerivedType(tag: DW_TAG_member, name: "b", scope: !10,
  file: !5, baseType: !15, size: 32, align: 32, offset: 64,
  flags: DIFlagPublic)
!15 = !DIBasicType(name: "i32", size: 32, encoding: DW_ATE_signed)
!16 = !{}
!17 = !DIDerivedType(tag: DW_TAG_member, name: "Second", scope: !7,
  file: !5, baseType: !18, size: 96, align: 32, extraData: i32 1)
!18 = !DICompositeType(tag: DW_TAG_structure_type, name: "Second",
  scope: !4, file: !5, size: 96, align: 32, flags: DIFlagPublic,
  elements: !19, templateParams: !16,
  identifier: "a2094b1381f3082d504fbd0903aa7c06")
!19 = !{!20}
!20 = !DIDerivedType(tag: DW_TAG_member, name: "__0", scope: !18,
  file: !5, baseType: !13, size: 32, align: 32, offset: 32,
  flags: DIFlagPublic)
```

BPF backend was assuming that all the elements of any `DICompositeType`
have tag `DW_TAG_member` and are instances of `DIDerivedType`. However,
the single element of the outer composite type `!4` has tag
`DW_TAG_variant_part` and is an instance of `DICompositeType`. The
unconditional call of `cast` on all elements was causing
an assertion failure when any Rust code with enums was compiled to the
BPF target.

Fix that by:

* Handling `DW_TAG_variant_part` in `visitStructType`.
* Replacing unconditional call of `cast` over
`DICompositeType` elements with a `switch` statement, handling both
`DW_TAG_member` and `DW_TAG_variant_part` and casting the element to an
appropriate type (`DIDerivedType` or `DICompositeType`).

Fixes: https://github.com/llvm/llvm-project/issues/155778
---
 llvm/lib/Target/BPF/BTFDebug.cpp  | 112 ++
 llvm/test/CodeGen/BPF/BTF/variant-part.ll |  87 +
 2 files changed, 180 insertions(+), 19 deletions(-)
 create mode 100644 llvm/test/CodeGen/BPF/BTF/variant-part.ll

diff --git a/llvm/lib/Target/BPF/BTFDebug.cpp b/llvm/lib/Target/BPF/BTFDebug.cpp
index 1e29a0f1e85a1..4ec7a93891aef 100644
--- a/llvm/lib/Target/BPF/BTFDebug.cpp
+++ b/llvm/lib/Target/BPF/BTFDebug.cpp
@@ -14,6 +14,7 @@
 #include "BPF.h"
 #include "BPFCORE.h"
 #include "MCTargetDesc/BPFMCTargetDesc.h"
+#include "llvm/BinaryFormat/Dwarf.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/CodeGen/AsmPrinter.h"
 #include "llvm/CodeGen/MachineModuleInfo.h"
@@ -23,6 +24,7 @@
 #include "llvm/MC/MCObjectFileInfo.h"
 #include "llvm/MC/MCSectionELF.h"
 #include "llvm/MC/MCStreamer.h"
+#include "llvm/Su

[llvm-branch-commits] [llvm] release/21.x: [BPF] Backport backend fixes related to BTF (PR #165154)

2025-10-26 Thread Michal R via llvm-branch-commits

vadorovsky wrote:

Thanks and sorry for not using the cherry-pick command

https://github.com/llvm/llvm-project/pull/165154
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/21.x: [BPF] Backport backend fixes related to BTF (PR #165154)

2025-10-27 Thread Michal R via llvm-branch-commits

vadorovsky wrote:

> So looks like llvm21 will have an assertion for rust if without backport.

Yes, exactly.

> Does it have problems before llvm21 say llvm20?

Yes, the same problem occurs on LLVM 20 and earlier versions as well. But given 
that the Rust 1.91.0-beta is already using LLVM 21 and we should expect it to 
stabilize sometime soon (definitely before holidays / the end of year), I'm 
fine with backporting the fixes only to LLVM 21.

> In general, I am okay with backport so llvm21 can work for rust bpf part as 
> llvm22 may need some time to be available.

Thank you! Yes, without the backport to LLVM 21, the timeline would become 
pretty long - we could expect Rust nightly to switch to LLVM 22 around February 
2026 and a stable Rust version around spring 2026.


https://github.com/llvm/llvm-project/pull/165154
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits


[llvm-branch-commits] [llvm] release/21.x: [BPF] Backport backend fixes related to BTF (PR #165154)

2025-10-26 Thread Michal R via llvm-branch-commits

vadorovsky wrote:

@eddyz87 @c-rhodes Not sure if that's the correct way of proposing backports, 
but I don't have rights to add items to 
https://github.com/llvm/llvm-project/milestone/27. I would appreciate your 
review!

https://github.com/llvm/llvm-project/pull/165154
___
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits