I have a code of main(), that is placed in ISO.c file. lines 164-173 contain this code:
player.scene_item->x = to_x(player.x, player.y, player.z),
player.scene_item->y = to_y(player.x, player.y, player.z),
player.scene_item->coords = to_coords(player.x, player.y, player.z);
// copy scene to RAM
scene_count = copy_scene(position->room_bank, position->room, scene_items);
// if scene not empty
if (scene_count) {
and far below in the same main() function on lines 314-317 i have that code:
clear_shadow_buffer();
// decompress scene to 3D map
scene_count = copy_scene(position->room_bank, position->room, scene_items);
if (scene_count) scene_to_map(scene_items, &collision_buf); else clear_map(&collision_buf);
when i compile that code with --debug switch, i get that ASM code for the first case:
call _clear_shadow_buffer
C$ISO.c$316$3_0$153 = .
.globl C$ISO.c$316$3_0$153
;src\ISO.c:316: scene_count = copy_scene(position->room_bank, position->room, scene_items);
C$ISO.c$170$1_0$123 = .
.globl C$ISO.c$170$1_0$123
;src\ISO.c:170: scene_count = copy_scene(position->room_bank, position->room, scene_items);
; genAssign
;fetchPairLong
;fetchLitPair
ld hl, #_position + 1
and this ASM code for the second:
;src\ISO.c:314: clear_shadow_buffer();
; genCall
call _clear_shadow_buffer
C$ISO.c$316$3_0$153 = .
.globl C$ISO.c$316$3_0$153
;src\ISO.c:316: scene_count = copy_scene(position->room_bank, position->room, scene_items);
C$ISO.c$170$1_0$123 = .
.globl C$ISO.c$170$1_0$123
;src\ISO.c:170: scene_count = copy_scene(position->room_bank, position->room, scene_items);
; genAssign
;fetchPairLong
at the end, in the map file we have:
00001B53 C$ISO.c$314$3_0$153 ISO
[cut]
00001B56 C$ISO.c$170$1_0$123 ISO
[cut]
00001B5D C$ISO.c$316$3_0$153 ISO
so:
1. the label for line 170 is set to some correct address near the beginning, and then gets overwritten with the incorrect address 00001B56 later.
2. label for line 316 is set to some incorrect address near the beginning, and then get overwritten by a correct address.
those labels are required for debug adapter for vs.code, that is almost working, but fails to break on some lines due to this problem.
some kind of reverse resolving of a label by the source line content?
Hmm, at first this looks like some redundancy elimination might move around code common to both lines, so in the end we don't really know which asm lines came from which C lines?
Do you see the same problem when compiling with some optimizations disabled, e.g. by using --nolospre or --nogcse?
--nolospre fixes the issue. isn't it possible to resolve that somehow? at least maybe total absence of those labels will be less confusing than duplicates?
hm... __3276800011 is a local register-allocated variable that is bind to no registers? names are ok, they are static.