Disassemble function shows wrong output for atmelavr + avr-stub

[maxgerhardt]

With a platformio.ini of

[env:uno]
platform = atmelavr
board = uno
framework = arduino
debug_tool = avr-stub
debug_port = \\.\COM14
; GDB stub implementation
lib_deps =
    jdolinay/avr-debugger @ ~1.1

and src\main.cpp

#include "Arduino.h"
#include "avr8-stub.h"

void setup()
{
  // initialize GDB stub
  debug_init();
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  digitalWrite(LED_BUILTIN, HIGH);
  delay(100);
  digitalWrite(LED_BUILTIN, LOW);
  delay(100);
}

Debugging starts normally and I can step over functions etc.

However, the "switch to disassembly" button in the VSCode unified debugger is not working (does nothing). Also, the "disassemble function" button gives the wrong output.

When I do disassemble setup in the Debug Console (=gdb console) I get

disassemble setup
Dump of assembler code for function setup:
   0x000011a4 <+0>: call    0x116e  ;  0x116e <debug_init>
   0x000011a8 <+4>: ldi r22, 0x01   ; 1
   0x000011aa <+6>: ldi r24, 0x0D   ; 13
   0x000011ac <+8>: call    0x218   ;  0x218 <pinMode>
   0x000011b0 <+12>:    ret
End of assembler dump.

when using the button "Disassemble function" I get

0x008011a4: 00 00               nop
0x008011a6: 00 00               nop
0x008011a8: 00 00               nop
0x008011aa: 00 00               nop
0x008011ac: 00 00               nop
0x008011ae: 00 00               nop
0x008011b0: 00 00               nop

notice the different address 0x008011a4.

This issue was already discussed at https://community.platformio.org/t/avr-simulator-as-aid-tool-for-debugging-code/13444/31 where it initially had something to do with a buggy GDB version that interpreted code addresses as data addresses, which map to different memories in the AVR architecture (Harvard architecture). Then a fixed version was created and used as a package (I think, can't quite remember)

However if a disassemble setup GDB command does produce the right output, then the PIO unified debugger should be able to use that, too. Maybe it uses a different command to extract the disassembly and that triggers that avr-gdb bug again. Since I don't know where the code is for executing that GDB command, I can't verify that.

Either way, the combination above is not working in the GUI well, thus this bug here.