Addition for LoongArch32 and LoongArch64

[VCZYK]

Add machine type and base relocation constants for LoongArch 32-bit and 64-bit processor families.

[PRMerger6]

@VCZYK : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[Karl-Bridge-Microsoft]

@VCZYK - Let me know when reviews are complete and topic is ready to publish.

[spbrogan]

for what my review is worth this looks aligned with what was agreed upon.

[RussKeldorph]

@Karl-Bridge-Microsoft This is ready when you are.

[kilaterlee]

Dear @RussKeldorph @VCZYK @spbrogan @Karl-Bridge-Microsoft ,

Our team is very happy to learn that the PE/COFF format of LoongArch has been updated.

Thank you both for your help. :)

[kilaterlee]

Dear @VCZYK @Karl-Bridge-Microsoft ,
I have two more questions about PE/COFF SPEC:

1. In the Base Relocation Types section, number 6 is reserved, why reserve it? Is there any wrong with it?
2. In the Base Relocation Types section, ten numbers are defined, if not enough, can we add more numbers?

Hope you reply!

Thanks,
Chao.

[RussKeldorph]

@kilaterlee

In the Base Relocation Types section, number 6 is reserved, why reserve it? Is there any wrong with it?

All of the currently unused base relocation types are reserved. Number 6 was previously allocated to an architecture that is no longer--or never was publicly--supported.

In the Base Relocation Types section, ten numbers are defined, if not enough, can we add more numbers?

There are 16 possible base relocation types for a given machine type, and additional ones can be defined if required by a particular architecture. Given the extreme restriction on total number, however, a strong case must be made to justify each one. I am not aware of a hard rule governing allocation, but we would probably first allocate the machine-dependent numbers (5, 7, 8, & 9) for additional machine-dependent meanings before allocating currently unallocated numbers, since allocating new numbers means they could not be used for a machine-independent purpose in the future.

[kilaterlee]

@kilaterlee

In the Base Relocation Types section, number 6 is reserved, why reserve it? Is there any wrong with it?

All of the currently unused base relocation types are reserved. Number 6 was previously allocated to an architecture that is no longer--or never was publicly--supported.

In the Base Relocation Types section, ten numbers are defined, if not enough, can we add more numbers?

There are 16 possible base relocation types for a given machine type, and additional ones can be defined if required by a particular architecture. Given the extreme restriction on total number, however, a strong case must be made to justify each one. I am not aware of a hard rule governing allocation, but we would probably first allocate the machine-dependent numbers (5, 7, 8, & 9) for additional machine-dependent meanings before allocating currently unallocated numbers, since allocating new numbers means they could not be used for a machine-independent purpose in the future.

Dear @RussKeldorph ,
I get it, referring to what you said, machine-dependencies can only assign numbers 5, 7, 8 and 9, a factual question about the LoongArch architecture that there are four new machine-dependent base relocation types may need to be added, in the LoongArch architecture, number 8 has now already assigned, there are only three numbers left to assign, I think it is not enough, so what's your advice on this issue?

[RussKeldorph]

@kilaterlee I wrote that 5, 7, 8, and 9 would be allocated to machine-dependent purposes before allocating a new one. That said, one architecture needing at least five machine-dependent relocations is highly unusual. You'd need to provide clear and convincing evidence to justify them.

[kilaterlee]

Dear @RussKeldorph ,

Sorry for replying so late, I was a little busy other day.

Okay, I see, I think I will talk to you about this issue later, when I will describe the new relocation types in detail to you. :)

Thanks,
Chao