Will the output from the Ozone code profile listing for the "load" metric be valid for functions that are moved to a run-from-RAM section via a gcc attribute?
e.g. __attribute__ ((section (".fast"))) , with the .fast section located in the RAM segment by the linker script .
I don't have a minimum working example to reproduce at the moment, I am just observing this in the context of a large/complex program where I am trying to accelerate some crypto functions.
When I move some of the functions that were reading a high "Load" percentage via code profile into RAM, I am still seeing the "Run count" increase, but the "Load" goes from ~7% to 0.01%.
Since that is a surprisingly large difference for a relatively simple function (128B, mbedtls_mpi_cmp_mpi from the mbed TLS library), I have some concern that the code profiler is getting confused. But I do see mbedtls_mpi_cmp_mpi and _mbedtls_mpi_cmp_mpi_veneer both detected, both listed with accurate addresses in RAM & flash respectively, and the run counts increasing together.
So I am unsure ...
e.g. __attribute__ ((section (".fast"))) , with the .fast section located in the RAM segment by the linker script .
I don't have a minimum working example to reproduce at the moment, I am just observing this in the context of a large/complex program where I am trying to accelerate some crypto functions.
When I move some of the functions that were reading a high "Load" percentage via code profile into RAM, I am still seeing the "Run count" increase, but the "Load" goes from ~7% to 0.01%.
Since that is a surprisingly large difference for a relatively simple function (128B, mbedtls_mpi_cmp_mpi from the mbed TLS library), I have some concern that the code profiler is getting confused. But I do see mbedtls_mpi_cmp_mpi and _mbedtls_mpi_cmp_mpi_veneer both detected, both listed with accurate addresses in RAM & flash respectively, and the run counts increasing together.
So I am unsure ...