On 2023/12/13 22:45, Mark Rutland wrote: > On Wed, Dec 13, 2023 at 05:01:07PM +0800, Wang wrote: >> On 2023/12/13 16:48, Dan Li wrote: >>> + Likun >>> >>> On Tue, 28 Mar 2023 at 06:18, Sami Tolvanen wrote: >>>> On Mon, Mar 27, 2023 at 2:30 AM Peter Zijlstra wrote: >>>>> On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote: >>>>> >>>>>> In the compiler part[4], most of the content is the same as Sami's >>>>>> implementation[3], except for some minor differences, mainly including: >>>>>> >>>>>> 1. The function typeid is calculated differently and it is difficult >>>>>> to be consistent. >>>>> This means there is an effective ABI break between the compilers, which >>>>> is sad :-( Is there really nothing to be done about this? >>>> I agree, this would be unfortunate, and would also be a compatibility >>>> issue with rustc where there's ongoing work to support >>>> clang-compatible CFI type hashes: >>>> >>>> https://github.com/rust-lang/rust/pull/105452 >>>> >>>> Sami >> >> Hi Peter and Sami >> >> I am Dan Li's colleague, and I will take over and continue the work of CFI. >> >> Regarding the issue of gcc cfi type id being compatible with clang, we >> have analyzed and verified: >> >> 1. clang uses Mangling defined in Itanium C++ ABI to encode the function >> prototype, and uses the encoding result as input to generate cfi type id; >> 2. Currently, gcc only implements mangling for the C++ compiler, and the >> function prototype coding generated by these interfaces is compatible >> with clang, but gcc's c compiler does not support mangling.; >> >> Adding mangling to gcc's c compiler is a huge and difficult task，because >> we have to refactor the mangling of C++, splitting it into basic >> mangling and language specific mangling, and adding support for the c >> language which requires a deep understanding of the compiler and >> language processing parts. >> >> And for the kernel cfi, I suggest separating type compatibility from CFI >> basic functions. Type compatibility is independent from CFI basic >> funcitons and should be dealt with under another topic. Should we focus >> on the main issus of cfi, and let it work first on linux kernel, and >> left the compatible issue to be solved later? > > I'm not sure what you're suggesting here exactly, do you mean to add a type ID > scheme that's incompatible with clang, leaving everything else the same? If > so, > what sort of scheme are you proposing? > > It seems unfortunate to have a different scheme, but IIUC we expect all kernel > objects to be built with the same compiler. > > Mark.
Thanks Mark, I will consider a scheme that is compatible with clang. Likun Wang. 声明：这封邮件只允许文件接收者阅读，有很高的机密性要求。禁止其他人使用、打开、复制或转发里面的任何内容。如果本邮件错误地发给了你，请联系邮件发出者并删除这个文件。机密及法律的特权并不因为误发邮件而放弃或丧失。任何提出的观点或意见只属于作者的个人见解，并不一定代表本公司。
