https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Robert Dubner <rdubner at symas dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdubner at symas dot com
--- Comment #2 from Robert Dubner <rdubner at symas dot com> ---
Based on your report I am going to disable assembler messages and see what
happens. I expect, and hope, that the resulting executables will work.
I had reasons for putting them in there.
I have been making changes to GDB so that it can be used to debug these COBOL
executables.
We've touched on the COBOL construction
0010 PERFORM FOO
0011 [...]
0020 FOO.
0021 DISPLAY "I am FOO".
0022 BAR.
0023 [...]
It behaves like a function; PERFORM FOO results in "I am FOO", and then
execution returns to line 0011.
But it is not implemented with a call. It is implemented with goto
instructions, and the stack frame doesn't change.
This creates challenge for GDB, because when stopped at line 0010, a gdb "next"
command should cause execution to pass through FOO without stopping, and then
the next stop should be at line 0011.
I create the .proccall and .procret and _para.[...] symbols in those specific
forms so that GDB can find them in the symbol table and take appropriate
action. .proccall and .procret give the boundaries of "next" activity, and the
.para[...] provides information that GDB can use to implement "break FOO".
I knew I would have to fix this, someday, and I guess "someday" is making its
appearance.
Instead of trying to pass metadata by using labels as a communications medium,
I now need to learn how to put arbitrary information into the ELF .debug_info
section. And then I have to learn how to extract it from inside GDB.
Has anybody any suggestions?
