Closed grahambates closed 1 year ago
As it turns out, the very simple solution for my use case is to not have a linker step and just use the vasm elf output directly, as I only have a single object. This leaves the section name intact and doesn't have the problem with VMA.
It would still be good to think about how to deal with code memory types in a larger program though.
IAmigaProfileExtra.pcTrace
is PC relative to .text
.cpu_profiler_start_addr
, and you're correct in that this is simply the first section of the exe hunk file
So, all in all, this would be quite a bit of work to support multiple code sections.Ok that makes sense. I suppose it's a pretty niche requirement anyway! For me it was for creating an exe preview of a bootblock intro where I'm using pc-relative references to copper and audio data. Skipping the linker works fine for this.
On a recent project I had a need to put my code in chip RAM (I have my reasons!). What I found was:
.text.MEMF_CHIP
then the suffix gets lost at the linking stage and just folded into.text
. This means that elf2hunk doesn't assign the correct memory type..text
prefix e.g.something.MEMF_CHIP
then things seem mostly ok. The program runs and gdb debugs it. Where things go wrong is in the profiler. There are some hard coded references to.text
to locate the code section, but I was able to fix these by making it default to the first section if not found. The remaining problem is that the PC offsets are wrong, meaing the current line is not found in the disassembly view. This is because the elf has a non-zero LMA/VMA for the section.We could just adjust for this offset but I feel like I'm a bit out of my depth in that I don't really understand the behaviour around the
.text
name in GCC and I'd be interested to hear your thoughts.