arhc/arm64: vector table may be far away form arm64_fatal_handle

[lipengfei28]

use 33-bit (+/-4GB) pc-relative addressing to load the address of arm64_fatal_handle Some project，the vector table in TCM， but the arm64_fatal_handle in ddr，this case vector table may be far away form arm64_fatal_handle

Impact

Update this section, where applicable, on how change affects users, build process, hardware, documentation, security, compatibility, etc.

Testing

Update this section with details on how did you verify the change, what Host was used for build (OS, CPU, compiler, ..), what Target was used for verification (arch, board:config, ..), etc. Providing build and runtime logs from before and after change is highly appreciated.

[nuttxpr]

[Experimental Bot, please feedback here]

NuttX PR Requirements Review

The provided PR description is missing crucial information to meet the NuttX requirements.

Here's a breakdown:

Summary:

• Missing: A clear explanation of why this change is necessary. Is it fixing a bug? Enhancing performance? Provide context.
• Insufficient: "Some project..." is too vague. Specify which projects/configurations are affected by this issue.
• Missing: How does the use of 33-bit PC-relative addressing specifically solve the described problem?

Impact:

• Incomplete: The impact section is entirely blank. You must address each point, stating "NO" or providing a detailed explanation if "YES". Consider:
  • Users: Will any user code need modification?
  • Build: Will any build flags or configurations be affected?
  • Hardware: Which architectures/boards are impacted?
  • Documentation: Does this change require documentation updates?
  • Security: Are there any potential security implications of this change?
  • Compatibility: Does this affect compatibility with older NuttX versions, different architectures, or external tools?

Testing:

• Completely Missing: You must provide:
  • Details about your build host environment (OS, CPU, compiler version)
  • Details about the target(s) you tested on (architecture, board, configuration)
  • Build logs (ideally, with make V=1) from before and after the change
  • Relevant runtime logs demonstrating the issue and the fix

Recommendations:

1. Expand the Summary: Clearly explain the problem, the solution, and why it's important.
2. Complete the Impact Section: Address each point thoroughly, even if it's just "NO".
3. Provide Detailed Testing Information: Show evidence that your change works as intended. Include build logs, runtime logs, and specific details about your testing environment.

By providing this missing information, you'll make your PR much easier to review and merge.