On Sun, Mar 27, 2022 at 09:09:20AM +0000, Christophe Leroy wrote: > Second point is the endianess and 32/64 selection, especially when > crossbuilding. There is already some stuff regarding endianess based on > bswap_if_needed() but that's based on constant selection at build time > and I couldn't find an easy way to set it conditionaly based on the > target being built. > > Regarding 32/64 selection, there is almost nothing, it's based on using > type 'long' which means that at the time being the target and the build > platform must both be 32 bits or 64 bits. > > For both cases (endianess and 32/64) I think the solution should > probably be to start with the fileformat of the object file being > reworked by objtool.
Do we really need to detect the endianness/bitness at runtime? Objtool is built with the kernel, why not just build-in the same target assumptions as the kernel itself? > What are current works in progress on objtool ? Should I wait Josh's > changes before starting looking at all this ? Should I wait for anything > else ? I'm not making any major changes to the code, just shuffling things around to make the interface more modular. I hope to have something soon (this week). Peter recently added a big feature (Intel IBT) which is already in -next. Contributions are welcome, with the understanding that you'll help maintain it ;-) Some years ago Kamalesh Babulal had a prototype of objtool for ppc64le which did the full stack validation. I'm not sure what ever became of that. FWIW, there have been some objtool patches for arm64 stack validation, but the arm64 maintainers have been hesitant to get on board with objtool, as it brings a certain maintenance burden. Especially for the full stack validation and ORC unwinder. But if you only want inline static calls and/or mcount then it'd probably be much easier to maintain. -- Josh
