hca: Sometimes the script does not analyze all instructions

[kjetilos]

Hi,

This was seen in applications that pull in crtbegin.o into the .text section. It turns out that the hca script does not analyze the instruction sequence coming from functions in crtbegin.o. In my case the functions coming from crtbegin.o have a size of 0 in the symbol table and it looks like the hca script is using this metadata in order to limit the amount of instructions. This issue will again lead to the size reported by the hca tool to be different from the size reported by for instance riscv32-unknown-elf-size, which again will make it harder to compare risc-v codesize to for instance arm code.

I modified the hca script to print out the function address and the size that hca script thinks the function is as well as the number of bytes missing. Here is the output from my modified script:

...
func:00000150/_start  0x3e
func:0000018e/deregister_tm_clones  0x4
 ++ missing 22 bytes
func:000001a8/register_tm_clones  0x4
 ++ missing 32 bytes
func:000001cc/__do_global_dtors_aux  0x2
 ++ missing 46 bytes
func:000001fc/frame_dummy  0x4
 ++ missing 32 bytes
func:00000220/SystemMaxCoreClockGet  0xa
...

Is it possible to force the script to analyze all the content of the .text section?

[abukharmeh]

Hi,

This is done as sometimes there are some data that objdump think that are instructions after executable code, and it tries to match them to RV encodings and sometimes print them as valid instructions while they are not.

I think at some point I had a check if the file is stripped then ignore that boundaries check, but I am not sure that this would always produce accurate results. If I parsed instructions that are not really instructions as instructions, this would reduce the optimisation space and make instructions look worse than they are really.

If you would like to compare with ARM, maybe a simple awk script that sums the sizes of symbols in symbol table might do the trick !

Hope this explains it !

[kjetilos]

Ok, I have a workaround that I can use for now by using the linker script to place the code that is being ignored by the script in a separate output section.

[abukharmeh]

@kjetilos I think this can be closed this, right ?

[kjetilos]

Did you do some changes to the script to make it possible to analyze the functions coming from crtbegin.o?

[abukharmeh]

Oh, so you were referring to crtbegin.o ! Generally this would contain hand written assembly that wont be strictly following ABI, so some of the assumptions we make might be incorrect, so I prefer the script not analysing it by default.

Perhaps we can add a flag to override boundary check, so you can compare both results if need be ?

[kjetilos]

Yes that should work, or alternatively the script can take a begin+end address and analyze all code within that memory region.