I spent some time understanding why some automatic variables have positive and some have negative offsets. The esp/ebp usage seems to affected by the function name. The testcase that reported positive offsets and esp usage seems have done so because the function was named main. Changing the function name to xmain resulted in negative offsets and ebp relative offsets with correct offsets because there were no registers to save an the stack. I built shared.s using a couple of different optimization options and ebp was used to access the local variables. As long as the generated code uses ebp to access the local variables we have a change to get debug data working.
My current guess is if we can figure how to get gcc to account for the extra saved registers when generating .stabs, can get usable local variable displays in the debugger. Here are the .stabs for touch_pages:
.stabs says that dos_len is at -20 (14h), but we know from inspection that it is at -24h. 14h is correct relative to the esp value after the ebx, esi and ebx registers are pushed on the stack. If we could convince gcc to take these pushes into account when generating the .stabs offsets the HLL debug data would be correct.
I guess we miss some target platform specific declarations in the .stabs generation code that accounts for how GCC actually generates code on OS/2. This might be related to some regressions of merging rather complex patches of our quite old OS/2 code (back from GCC 3 times) into newer versions.
By @StevenLevine from https://mantis.arcanoae.com/view.php?id=573#c21690:
I guess we miss some target platform specific declarations in the .stabs generation code that accounts for how GCC actually generates code on OS/2. This might be related to some regressions of merging rather complex patches of our quite old OS/2 code (back from GCC 3 times) into newer versions.