> On Aug 15, 2023, at 11:48 AM, Ard Biesheuvel <a...@kernel.org> wrote: > > On Tue, 15 Aug 2023 at 18:31, Andrew Fish via groups.io <http://groups.io/> > <afish=apple....@groups.io <mailto:afish=apple....@groups.io>> wrote: >> >> >> >>> On Aug 15, 2023, at 8:39 AM, Pedro Falcato <pedro.falc...@gmail.com> wrote: >>> >>> On Tue, Aug 15, 2023 at 4:05 PM Andrew Fish via groups.io >>> <afish=apple....@groups.io> wrote: >>>> >>>> Chao, >>>> >>>> From a quick google it looks like CSR* is used to access banks of >>>> registers that relate to things like performance counters and debug >>>> infrastructure and the number of banks of these register sets is likely >>>> implementation defined. Seems like we could introduce some Fixed At Build >>>> PCD values that define the maximum number of elements in a given bank. >>>> >>>> If we are forced to use assembler it might be possible to write some >>>> macros that used the fixed at build values to only generate functions for >>>> banks that are needed for a given build. Then I think it becomes an >>>> exercise in dead code stripping the assembler. Most compilers generate >>>> assembler that contains functions that can be stripped as long as those >>>> functions follow certain rules. >>>> >>>> As a side note it would be good for us to have an FAQ/Wiki entry for the >>>> dead code stripping rules for the various flavors of assembler. I know the >>>> Apple assembler has a unique take on this. >>> >>> FWIW, I'm almost positive there's no DCE in GNU as (or llvm-as as >>> well). Unless you use something ffunction-sections >>> -fdata-sections-like, but then you're relying on the linker + >>> gc-sections to take care of it, just like GCC/clang would. >>> >> >> I guess I usually think of DCE as a linker job, since the linker knows the >> functions that are NOT called. At least from the Apple tools the DCE has the >> same rules if you are using Link Time Optimization or not. It is basically a >> flag in the object that tells the inker it is OK to follow the DCE rules >> around labels and remove stuff. >> >> Worst case it seems like we could have macros that generate assembly files >> based on build time constants so we have one function per file. This might >> take a tweak to the build system, but I’d rather do that than have library >> functions that magically turn on Self Modifying Code. >> >> Regardless of the answer I think documenting the rules is a useful exercises >> since needing to save size in firmware images is not an uncommon task. >> > > There is already prior art in MdePkg where code targeting both GCC and > VS uses inline asm, so I don't see why we would make our lives > difficult and deviate from that for LoongArch. >
If you look at the BaseLib you can see an example of the INF file[1] using C inline assembler for the GCC family[2] of compilers and NASM for the MSFT [3] tools. Maybe you can plan on using a similar pattern. [1] https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/BaseLib.inf#L321 [2] https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/GccInline.c [3] https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/CpuPause.nasm Thanks, Andrew Fish > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107772): https://edk2.groups.io/g/devel/message/107772 Mute This Topic: https://groups.io/mt/100751724/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
