Hi Alan, On Thu Jun 19, 2025 at 5:41 PM CEST, Alan Maguire wrote: > On 19/06/2025 14:12, Alexis Lothoré wrote: >> On Wed Jun 18, 2025 at 6:28 PM CEST, Alexei Starovoitov wrote: >>> On Wed, Jun 18, 2025 at 8:02 AM Alexis Lothoré >>> <alexis.lothore@xxxxxxxxxxx> wrote: [...] >>> though it's passed on the stack it fits into normal calling convention. >>> It doesn't have align or packed attributes, so no need to exclude it ? >> >> I went for the simplest solution, assuming that there were cases involving >> packing/alignent customization that we would not be able to detect (eg: the >> packed attr that does not change size but reduce alignment). But thinking >> more about it, those cases need really specific conditions thay may not >> exist currently in the kernel (eg: having some __int128 embedded in a >> struct). >> >> I see that pahole already has some logic to check if a struct is >> altered (eg class__infer_packed_attributes), I'll check if I can come with >> something more selective. >> > > sounds good; one additional suggestion is given that these sorts of > functions are rare to nonexistent in vmlinux, perhaps we could add some > tests to the tests/ directory that compile C code and generate BTF from > the associated DWARF, verifying that functions are (or are not) encoded > as expected? > > I'm working on adding automatic comparison of vmlinux BTF function > encoding for candidate patch series to pahole's CI (so we can see if > functions appear/disappear), but in a case like this a few explicit > tests would be great to have. Thanks! Yes, sure. I did not consider at all tests while the series is in RFC, but I had it in mind for the next steps. I'll take into account the need to add and build automatically some custom C code exposing those "exotic" functions and structs. Alexis. -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
