[Bug]: [GenFw] FindPrmHandler in Elf64Convert.c assumes symbol value is file offset #550
Closed
1 task done
Labels
state:needs-maintainer-feedback
Needs more information from a maintainer to determine next steps
state:needs-triage
Needs to triaged to determine next steps
state:stale
Has not been updated in a long time
type:bug
Something isn't working
urgency:low
Little to no impact
Is there an existing issue for this?
Current Behavior
When GenFw is ran with the --prm option, it will attempt to locate the PrmModuleExportDescriptor symbol as part of the ScanSections64 function call. Once found, it will pass its 'st_value' field value into FindPrmHandler as an offset to find the location of PRM handler symbols in the file, as seen here:
mu_basecore/BaseTools/Source/C/GenFw/Elf64Convert.c
Line 991 in 5498883
However, st_value does not necessarily represent the offset of a symbol in the file. It appears to actually represent the VMA of the symbol. For example, on my build, PrmModuleExportDescriptor is placed in the .data section, which has a VMA of 0x6000, but the .data section is actually at file offset 0x7000. So, when st_value is passed into FindPrmHandler, the function begins looking at offset 0x6000 for PRM handlers rather than 0x7000.
A potential fix (which works on my build) is to calculate the symbol offset by first finding the section header it belongs to using the symbol's st_shndx field. Then, subtract the section's address from the symbol's address before finally adding the section offset, like this:
Thus, anytime a symbol's value is treated as an offset, this function should be used instead.
Expected Behavior
I expect GenFw, when ran with the --prm option, to locate PRM-related symbols in an ELF file regardless of what their VMA value is.
Steps To Reproduce
Build Environment
Version Information
Urgency
Low
Are you going to fix this?
I will fix it
Do you need maintainer feedback?
Maintainer feedback requested
Anything else?
This shows .data has a VMA that is not equal to its file offset:
This shows PrmModuleExportDescriptor has a symbol value of 0x6000 (since it's the first symbol in .data):
And this shows PrmModuleExportDescriptor actually has a file offset of 0x7000 (thus the symbol's value is not its offset):
The text was updated successfully, but these errors were encountered: