Giters

BartmanAbyss / vscode-amiga-debug

One-stop Visual Studio Code Extension to compile, debug and profile Amiga C/C++ programs compiled by the bundled gcc 12.2 with the bundled WinUAE/FS-UAE.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Memory types in code sections

grahambates opened this issue · comments

commented

On a recent project I had a need to put my code in chip RAM (I have my reasons!). What I found was:

  • If the section name follows the convention .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.
  • If you don't use the .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.
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000002e8  00000000  00000000  00002000  2**1

Idx Name                Size      VMA       LMA       File off  Algn
  0 something.MEMF_CHIP 000002e8  80000074  80000074  00000074  2**1

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.

commented

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.

commented
  • Yes, all .text., .data., .bss.* get merged into one text, data, bss section by the linker script.
  • For profiling, there could be several problems: IAmigaProfileExtra.pcTrace is PC relative to .text.
  • Also, the profiling data WinUAE writes out is PC relative to 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.
commented

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.