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.  

Thanks,

Andrew Fish

On Aug 15, 2023, at 1:54 AM, Chao Li <lichao@loongson.cn> wrote:

Hi Ard,

Ok, I see, thanks for you suggestion.


Thanks,
Chao
在 2023/8/15 16:28, Ard Biesheuvel 写道:
On Tue, 15 Aug 2023 at 10:20, Chao Li <lichao@loongson.cn> wrote:

Hi Andrew,

Yes, you are right, I also think that SMC is a bit flawed in terms of security, but can we use some security mechanism to protect the SMC, like encryption and decryption? Sorry, I'm not consider mature enough about SMC security.

I can tell you real problem, there are some CSR instructions in LoongArch64 that can only accept immediate value, for example: `csrrd $a0, 0x1`, the 0x1 is the selection of CSR register number, it can't use the registers to select. This operation should be in the MdePkg base library.


That is *not* a good reason for using self modifying code. If the CSR
register number is known at build time, it should be emitted into the
binary at build time in one way or another.


I know that .c or .h files in MdePkg shouldn't depend on a single compiler feature, so I can't use the GNU AT&T style inline ASM function(AT&T style inline supports input parameters being immedite value, use "i" option). In this case, I think using SMC can handle this, that is use register transfer the CSR registers selection, and dynamically modify CSR instructions during execution phase with reference to transfer register value, this way is depend on the .text section or target memory is executable and writable.

The problem of immediate values can only be handled by preprocessing stage or using SMC, otherwise I can only write a lot of similar functions and use `switch case` to call them. This method will cause the program size to expand a lot.

So, I think I have following choice:

Choice 1:

Use AT&T style inline function, and create a file named: CsrOperationGcc.c, and other future compiler feature-dependent files will be named: CsrOperationClang.c, CsrOperationXlang.c and so on.


If the only currently supported compiler (GCC?) has a syntax that
permits emitting this as inline asm, it is perfectly fine to use this
in your implementation. Once other compiler support is introduced, we
can think about how to address the difference, but I suspect that
Clang will just work with the GCC notation.

_._,_._,_
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#107766) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_