| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ff16cf710aeb4008b3dafdbd68ab93c7@BJMBX01.spreadtrum.com>
Date: Wed, 30 Jul 2025 09:44:51 +0000
From: 刘海燕 (Haiyan Liu) <haiyan.liu@...soc.com>
To: Ard Biesheuvel <ardb@...nel.org>, Mark Rutland <mark.rutland@....com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"rust-for-linux@...r.kernel.org"
<rust-for-linux@...r.kernel.org>,
代子为 (Ziwei Dai)
<Ziwei.Dai@...soc.com>,
周平 (Ping Zhou/9032)
<Ping.Zhou1@...soc.com>,
杨丽娜 (Lina Yang)
<lina.yang@...soc.com>,
王双 (Shuang Wang)
<shuang.wang@...soc.com>,
Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda
<ojeda@...nel.org>,
Matthew Maurer <mmaurer@...gle.com>,
Sami Tolvanen
<samitolvanen@...gle.com>
Subject: 答复: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS on
> -----邮件原件-----
> 发件人: Ard Biesheuvel <ardb@...nel.org>
> 发送时间: 2025年7月21日 14:10
> 收件人: Mark Rutland <mark.rutland@....com>
> 抄送: 刘海燕 (Haiyan Liu) <haiyan.liu@...soc.com>; linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> rust-for-linux@...r.kernel.org; 代子为 (Ziwei Dai) <Ziwei.Dai@...soc.com>; 周平 (Ping Zhou/9032) <Ping.Zhou1@...soc.com>; 杨丽
> 娜 (Lina Yang) <lina.yang@...soc.com>; 王双 (Shuang Wang) <shuang.wang@...soc.com>; Alice Ryhl <aliceryhl@...gle.com>; Miguel
> Ojeda <ojeda@...nel.org>; Matthew Maurer <mmaurer@...gle.com>; Sami Tolvanen <samitolvanen@...gle.com>
> 主题: Re: Meet compiled kernel binaray abnormal issue while enabling generic kasan in kernel 6.12 with some default KBUILD_RUSTFLAGS
> on
>
>
> 注意: 这封邮件来自于外部。除非你确定邮件内容安全，否则不要点击任何链接和附件。
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
> and know the content is safe.
>
>
>
> On Thu, 17 Jul 2025 at 20:39, Mark Rutland <mark.rutland@....com> wrote:
> >
> > Hi,
> >
> > From a quick scan, I think this might have something to do with
> > UNWIND_PATCH_PAC_INTO_SCS, notes below.
> >
> > On Mon, Jul 14, 2025 at 03:12:33AM +0000, 刘海燕 (Haiyan Liu) wrote:
> > > I am enabling generic kasan feature in kernel 6.12, and met kernel boot crash.
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 0000000000000008 pc : do_basic_setup+0x6c/0xac lr :
> > > do_basic_setup+0x88/0xac sp : ffffffc080087e40
> >
> > Can you say which hardware this is on? Given this is a
> > NULL-dereference, this looks ike a dodgy pointer (or memory
> > corruption) rather than a PAC failure.
> >
> > > After debug, I find some error in do_ctors().
> > > Normally, the complier should insert the paciasp instruction at the function entry so that its corresponding autiasp instruction is used to
> validate the return address when the function returns.
> > > NSX:FFFFFFC0800A840C|F800865E asan.module_ctor: str x30,[x18],#0x8；x30,[x18],#8
> > > NSX:FFFFFFC0800A8410|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A8414|910003FD mov x29,sp
> > > NSX:FFFFFFC0800A8418|B0023420 adrp x0,0xFFFFFFC08472D000
> > > NSX:FFFFFFC0800A841C|91390000 add x0,x0,#0xE40 ; x0,x0,#3648
> > > NSX:FFFFFFC0800A8420|528000A1 mov w1,#0x5 ; w1,#5
> > > NSX:FFFFFFC0800A8424|9422AF50 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A8428|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > NSX:FFFFFFC0800A842C|F85F8E5E ldr x30,[x18,#-0x8]! ; x30,[x18,#-8]!
> > > NSX:FFFFFFC0800A8430|D65F03C0 ret
> >
> > Here you evidently have shadow call stack enabled...
> >
> > > NSX:FFFFFFC0800A8478|D503233F asan.module_ctor: paciasp
> > > NSX:FFFFFFC0800A847C|A9BF7BFD stp x29,x30,[sp,#-0x10]! ; x29,x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A8480|910003FD mov x29,sp
> > > NSX:FFFFFFC0800A8484|B0023420 adrp x0,0xFFFFFFC08472D000
> > > NSX:FFFFFFC0800A8488|913E0000 add x0,x0,#0xF80 ; x0,x0,#3968
> > > NSX:FFFFFFC0800A848C|52800021 mov w1,#0x1 ; w1,#1
> > > NSX:FFFFFFC0800A8490|9422AF35 bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A8494|A8C17BFD ldp x29,x30,[sp],#0x10 ; x29,x30,[sp],#16
> > > NSX:FFFFFFC0800A8498|D50323BF autiasp
> > > NSX:FFFFFFC0800A849C|D65F03C0 ret
> >
> > ... but here you evidently don't, and have PAC instead.
> >
> > Are these from the same kernel Image?
> >
> > Are these decoded from the static kernel binary, or are these dumps
> > from memory once a kernel has booted (or is in the process of booting)?
> >
> > > But actually, in two asan.module_ctor functions, there is only autiasp instruction inserted before return, for validation of return
> address, while paciasp instruction is missing before.
> > > NSX:FFFFFFC0800A72D8|F800865E asan.module_ctor: str x30,[x18],#0x8 ; x30,[x18],#8
> > > NSX:FFFFFFC0800A72DC|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
> > > NSX:FFFFFFC0800A72E0|B00233C0 adrp x0,0xFFFFFFC084720000
> > > NSX:FFFFFFC0800A72E4|91350000 add x0,x0,#0xD40 ; x0,x0,#3392
> > > NSX:FFFFFFC0800A72E8|52803D61 mov w1,#0x1EB ; w1,#491
> > > NSX:FFFFFFC0800A72EC|9422B39E bl 0xFFFFFFC080954164 ; __asan_register_globals
> > > NSX:FFFFFFC0800A72F0|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
> > > NSX:FFFFFFC0800A72F4|D50323BF autiasp
> > > NSX:FFFFFFC0800A72F8|D65F03C0 ret
> >
> > Thas has a mixture of SCS and PAC; there's a shadow call stack
> > prologue but a PAC epilogue:
> >
> > str x30, [x18], #8 // SCS
> > ...
> > autiasp // PAC
> >
> > ... so I'll hazard a guess that these are dumps from memory, and you
> > have UNWIND_PATCH_PAC_INTO_SCS selected. Assuming that is the case,
> > either this dump has been made mid-patching, or the patching has gone
> > wrong somehow and left the prologues/epilogues in an inconsistent
> > state (and the NULL dereference could be a secondary effect of that).
> >
> > Ard, does that sound plausible to you?
> >
>
> Yes, that is definitely possible.
>
> Since commit 54c968bec344 ("arm64: Apply dynamic shadow call stack patching in two passes") we are more careful about patching a
> function in its entirety or not at all if any of the DWARF metadata is misunderstood (or invalid). However, if the DWARF metadata is
> inaccurate, but does not trigger an error, the patching will happen and an error such as this one is likely to occur as a result.
>
> Note that PACIASP and AUTIASP do not necessarily occur in pairs, so it is not generally feasible to validate the DWARF against the code,
> especially at runtime. However, a function (or FDE frame) that has one PACIASP should at least have one AUTIASP too.
>
> > I can't see why that would depend on KBUILD_RUSTFLAGS, but maybe the
> > DWARF generated by rustc has confused the patching code somehow, or
> > the linker has aggregated that in a suprising way.
> >
>
> I would suspect the DWARF metadata in this case. There are valid cases where the DW_CFA_negate_ra_state annotation is attached to an
> instruction other than PACIASP or AUTIASP, and so we are not able to detect the case where the annotation is misplaced (i.e., attached to
> the preceding or subsequent instruction).
>
> So the important thing to check here is whether the objects in question have the correct DWARF annotations for these
> asan.module_ctor() routines. This can be done using 'llvm-readelf --unwind' (example below, using an arbitrary object from a defconfig
> build with kasan, rust and dynamic shadow call stack enabled): in this case, both routines are correctly annotated, i.e., that the return
> address (RA) state toggles to signed at offset 0x4 and toggles back to unsigned/authenticated at 0x24.
>
>
>
>
> $ llvm-objdump -d kernel/seccomp.o
>
> Disassembly of section .text.asan.module_ctor:
>
> 0000000000000000 <asan.module_ctor>:
> 0: d503233f paciasp
> 4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
> 8: 910003fd mov x29, sp
> c: 90000000 adrp x0, 0x0 <asan.module_ctor>
> 10: 91000000 add x0, x0, #0x0
> 14: 528003c1 mov w1, #0x1e // =30
> 18: 94000000 bl 0x18 <asan.module_ctor+0x18>
> 1c: a8c17bfd ldp x29, x30, [sp], #0x10
> 20: d50323bf autiasp
> 24: d65f03c0 ret
>
> Disassembly of section .text.asan.module_dtor:
>
> 0000000000000000 <asan.module_dtor>:
> 0: d503233f paciasp
> 4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
> 8: 910003fd mov x29, sp
> c: 90000000 adrp x0, 0x0 <asan.module_dtor>
> 10: 91000000 add x0, x0, #0x0
> 14: 528003c1 mov w1, #0x1e // =30
> 18: 94000000 bl 0x18 <asan.module_dtor+0x18>
> 1c: a8c17bfd ldp x29, x30, [sp], #0x10
> 20: d50323bf autiasp
> 24: d65f03c0 ret
>
>
> $ llvm-readelf -u kernel/seccomp.o
>
> (this requires a bit of manual inspection, given that readelf does not take the .rela.eh_frame section into account, and so the initial
> locations are section relative, and you're looking for FDE frames that have initial location 0x0)
>
> ...
> [0x58c] FDE length=40 cie=[0x0]
> initial_location: 0x0
> address_range: 0x28 (end : 0x28)
>
> Program:
> DW_CFA_advance_loc: 4 to 0x4
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_advance_loc: 4 to 0x8
> DW_CFA_def_cfa_offset: +16
> DW_CFA_advance_loc: 4 to 0xc
> DW_CFA_def_cfa: reg29 +16
> DW_CFA_offset: reg30 -8
> DW_CFA_offset: reg29 -16
> DW_CFA_advance_loc: 16 to 0x1c
> DW_CFA_def_cfa: reg31 +16
> DW_CFA_advance_loc: 4 to 0x20
> DW_CFA_def_cfa_offset: +0
> DW_CFA_advance_loc: 4 to 0x24
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_restore: reg30
> DW_CFA_restore: reg29
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
>
> [0x5b8] FDE length=44 cie=[0x0]
> initial_location: 0x0
> address_range: 0x28 (end : 0x28)
>
> Program:
> DW_CFA_advance_loc: 4 to 0x4
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_advance_loc: 4 to 0x8
> DW_CFA_def_cfa_offset: +16
> DW_CFA_advance_loc: 4 to 0xc
> DW_CFA_def_cfa: reg29 +16
> DW_CFA_offset: reg30 -8
> DW_CFA_offset: reg29 -16
> DW_CFA_advance_loc: 16 to 0x1c
> DW_CFA_def_cfa: reg31 +16
> DW_CFA_advance_loc: 4 to 0x20
> DW_CFA_def_cfa_offset: +0
> DW_CFA_advance_loc: 4 to 0x24
> DW_CFA_AARCH64_negate_ra_state:
> DW_CFA_restore: reg30
> DW_CFA_restore: reg29
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
> DW_CFA_nop:
I find two question :
1. too many __unnamed global value in system.map, such as :
ffffffc082e63ba0 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data5cased17SHORT_OFFSET_RUNS
ffffffc082e63c20 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data5cased7OFFSETS
ffffffc082e63da0 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data15grapheme_extend17SHORT_OFFSET_RUNS
ffffffc082e63e60 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data15grapheme_extend7OFFSETS
ffffffc082e641e0 d __unnamed_340
ffffffc082e64280 d __unnamed_341
ffffffc082e64400 d __unnamed_342u
ffffffc082e64620 d __unnamed_343
ffffffc082e64680 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data1n17SHORT_OFFSET_RUNS
ffffffc082e64740 d _RNvNtNtNtCs3o2tGsuHyou_4core7unicode12unicode_data1n7OFFSETS
and I found the global values defined in '1.82.0/lib/rustlib/src/rust/library/core/src/unicode/Unicode_data.rs':
#[rustfmt::skip]
pub mod lowercase {
const BITSET_CHUNKS_MAP: &'static [u8; 123] = &[
14, 17, 0, 0, 9, 0, 0, 12, 13, 10, 0, 16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 4, 1, 0, 15, 0, 8, 0, 0, 11, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 19, 0,
3, 18, 0, 7,
];
const BITSET_INDEX_CHUNKS: &'static [[u8; 16]; 20] = &[
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 59, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 16, 14, 55, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 40, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 44, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 9, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0, 65, 43, 0, 51, 47, 49, 33],
[0, 0, 0, 0, 10, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 27],
[0, 0, 0, 60, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 57, 0, 55, 55, 55, 0, 22, 22, 67, 22, 36, 25, 24, 37],
[0, 5, 68, 0, 29, 15, 73, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 64, 34, 17, 23, 52, 53, 48, 46, 8, 35, 42, 0, 28, 13, 31],
[11, 58, 0, 6, 0, 0, 30, 0, 0, 0, 0, 0, 0, 0, 32, 0],
[16, 26, 22, 38, 39, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[16, 50, 2, 21, 66, 9, 57, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[16, 70, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
[63, 41, 54, 12, 75, 61, 18, 1, 7, 62, 74, 20, 71, 72, 4, 45],
];
const BITSET_CANONICAL: &'static [u64; 55] = &[
0b0000000000000000000000000000000000000000000000000000000000000000,
0b1111111111111111110000000000000000000000000011111111111111111111,
0b1010101010101010101010101010101010101010101010101010100000000010,
0b0000000000000111111111111111111111111111111111111111111111111111,
0b1111111111111111111111000000000000000000000000001111110111111111,
0b1000000000000010000000000000000000000000000000000000000000000000,
0b0000111111111111111111111111111111111111000000000000000000000000,
0b0000111111111111111111111111110000000000000000000000000011111111,
0b1111111111111111111111111111111111111111111111111010101010000101,
0b1111111111111111111111111111111100000000000000000000000000000000,
0b1111111111111111111111111111110000000000000000000000000000000000,
0b1111111111111111111111110000000000000000000000000000000000000000,
0b1111111111111111111111000000000000000000000000001111111111101111,
0b1111111111111111111100000000000000000000000000010000000000000000,
0b1111111111111111000000111111111111110111111111111111111111111111,
0b1111111111111111000000000000000000000000000000000100001111000000,
0b1111111111111111000000000000000000000000000000000000000000000000,
0b1111111101111111111111111111111110000000000000000000000000000000,
0b1111110000000000000000000000000011111111111111111111111111000000,
0b1111011111111111111111111111111111111111111111110000000000000000,
0b1111000000000000000000000000001111110111111111111111111111111100,
0b1010101010101010101010101010101010101010101010101101010101010100,
0b1010101010101010101010101010101010101010101010101010101010101010,
0b0101010110101010101010101010101010101010101010101010101010101010,
0b0100000011011111000000001111111100000000111111110000000011111111,
0b0011111111111111000000001111111100000000111111110000000000111111,
0b0011111111011010000101010110001011111111111111111111111111111111,
0b0011111100000000000000000000000000000000000000000000000000000000,
0b0011110010001010000000000000000000000000000000000000000000100000,
0b0011001000010000100000000000000000000000000010001100010000000000,
0b0001101111111011111111111111101111111111100000000000000000000000,
0b0001100100101111101010101010101010101010111000110111111111111111,
0b0000011111111101111111111111111111111111111111111111111110111001,
0b0000011101011100000000000000000000000010101010100000010100001010,
0b0000010000100000000001000000000000000000000000000000000000000000,
0b0000000111111111111111111111111111111111111011111111111111111111,
0b0000000011111111000000001111111100000000001111110000000011111111,
0b0000000011011100000000001111111100000000110011110000000011011100,
0b0000000000001000010100000001101010101010101010101010101010101010,
0b0000000000000000001000001011111111111111111111111111111111111111,
0b0000000000000000000001111110000001111111111111111111101111111111,
0b0000000000000000000000001111111111111111110111111100000000000000,
0b0000000000000000000000000001111100000000000000000000000000000011,
0b0000000000000000000000000000000000111010101010101010101010101010,
0b0000000000000000000000000000000000000000111110000000000001111111,
0b0000000000000000000000000000000000000000000000000000101111110111,
0b1001001111111010101010101010101010101010101010101010101010101010,
0b1001010111111111101010101010101010101010101010101010101010101010,
0b1010101000101001101010101010101010110101010101010101001001000000,
0b1010101010100000100000101010101010101010101110100101000010101010,
0b1010101010101010101010101010101011111111111111111111111111111111,
0b1010101010101011101010101010100000000000000000000000000000000000,
0b1101010010101010101010101010101010101010101010101010101101010101,
0b1110011001010001001011010010101001001110001001000011000100101001,
0b1110101111000000000000000000000000001111111111111111111111111100,
];
const BITSET_MAPPING: &'static [(u8, u8); 21] = &[
(0, 64), (1, 188), (1, 183), (1, 176), (1, 109), (1, 124), (1, 126), (1, 66), (1, 70),
(1, 77), (2, 146), (2, 144), (2, 83), (3, 93), (3, 147), (3, 133), (4, 12), (4, 6),
(5, 187), (6, 78), (7, 132),
];
#[rustc_const_unstable(feature = "const_unicode_case_lookup", issue = "101400")]
pub const fn lookup(c: char) -> bool {
super::bitset_search(
c as u32,
&BITSET_CHUNKS_MAP,
&BITSET_INDEX_CHUNKS,
&BITSET_CANONICAL,
&BITSET_MAPPING,
)
}
}
I want to know the rust value becomed unnamed after compilation is valid or not.
2.I find the wrong global value ffffffc08483e560 d __unnamed_356:
llvm-objdump disassemble:
Disassembly of section .text.asan.module_ctor:
0000000000000000 <.text.asan.module_ctor>:
0: 60 7d c4 e5 .word 0xe5c47d60
0000000000000004 <asan.module_ctor>:
4: d503233f paciasp
8: f81f0ffe str x30, [sp, #-0x10]!
c: 90000000 adrp x0, 0x0 <.text.asan.module_ctor>
10: 91000000 add x0, x0, #0x0
14: 52803d61 mov w1, #0x1eb // =491
18: 94000000 bl 0x18 <asan.module_ctor+0x14>
1c: f84107fe ldr x30, [sp], #0x10
20: d50323bf autiasp
24: d65f03c0 ret
But when the software running, I dump the disassemble using the TRACE32 is：
______________addr/line|code_____|label____|mnemonic________________|comment
NSX:FFFFFFC0800A7C40|F800865E asan.mod.:str x30,[x18],#0x8 ; x30,[x18],#8
NSX:FFFFFFC0800A7C44|F81F0FFE str x30,[sp,#-0x10]! ; x30,[sp,#-16]!
NSX:FFFFFFC0800A7C48|F00240A0 adrp x0,0xFFFFFFC0848BE000
NSX:FFFFFFC0800A7C4C|91158000 add x0,x0,#0x560 ; x0,x0,#1376
NSX:FFFFFFC0800A7C50|52803D61 mov w1,#0x1EB ; w1,#491
NSX:FFFFFFC0800A7C54|94233646 bl 0xFFFFFFC08097556C ; __asan_register_globals
NSX:FFFFFFC0800A7C58|F84107FE ldr x30,[sp],#0x10 ; x30,[sp],#16
___NSX:FFFFFFC0800A7C5C|D50323BF____________autiasp
NSX:FFFFFFC0800A7C60|D65F03C0 ret
And llvm-readdlf -u disassembly:
[0x14] FDE length=52 cie=[0x0]
initial_location: 0x4
address_range: 0x78 (end : 0x7c)
Program:
DW_CFA_advance_loc: 4 to 0x8
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_advance_loc: 4 to 0xc
DW_CFA_def_cfa_offset: +48
DW_CFA_advance_loc: 12 to 0x18
DW_CFA_def_cfa: reg29 +48
DW_CFA_offset: reg19 -8
DW_CFA_offset: reg20 -16
DW_CFA_offset: reg21 -24
DW_CFA_offset: reg22 -32
DW_CFA_offset: reg30 -40
DW_CFA_offset: reg29 -48
DW_CFA_advance_loc1: 80 to 0x68
DW_CFA_def_cfa: reg31 +48
DW_CFA_advance_loc: 12 to 0x74
DW_CFA_def_cfa_offset: +0
DW_CFA_advance_loc: 4 to 0x78
DW_CFA_AARCH64_negate_ra_state:
DW_CFA_restore: reg19
DW_CFA_restore: reg20
DW_CFA_restore: reg21
DW_CFA_restore: reg22
DW_CFA_restore: reg30
DW_CFA_restore: reg29
DW_CFA_nop:
DW_CFA_nop:
I can't find something wrong in the disassemble.
3.I disable CONFIG_UNWIND_PATCH_PAC_INTO_SCS , I dump the disassemble using the TRACE32 as the same as the objdump disassemble. Can the config be disabled in 6.12?
Thank you.
Powered by blists - more mailing lists