https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Robert Dubner from comment #7) > Well, I did ask for suggestions. I suppose it's not surprising I don't > really understand them. Yet. > > I should explain, a little further, the underlying problems. > > This, for example, is a modified sample from one of my GDB-COBOL test cases: > > 0009 display "before" > 0010 perform hello test before varying a from 1 by 1 until a > 3 > 0011 after b from 1 by 1 until b > 3 > 0012 after c from 1 by 1 until c > 3 > 0013 display "after" > > What I want to have happen in GDB -- with a -O0 build of the cobol program > -- is for the user to be able to step through the program. So, at 0009, the > "next" command produces "before" and it stops at 0010. > > At that point the user commands "next", and we see the output of the hello > paragraph twenty-seven times. Yes, indeed, that construct iterates (a,b,c) > as (1,1,1) (1,1,2) (1,1,3) (1,2,1) (1,2,2) (1,2,3) (1,2,2)..., and executes > the "hello" paragraph for each. And, yes, it does all that with a single > COBOL statement > > And then the debugger stops at line 0013. > > I managed to do this by putting a .proccall label into the assembly language > at line 10, and by putting a matching .procret label into the assembly > language near at the target location for where execution passes when all of > the conditions for completion are satisfied. > > In GDB, I notice at "next_command" time that the source line number matches > the location of the .proccall, meaning that I need to set a temporary > breakpoint at the place where .proccret is. And then I issue a "continue" > instead of a "next". > > When a breakpoint is encountered, I check to see if it is at a .procret > location, and, if so, I issue a "next", which brings execution back to the > "return" location. > > I am interested in the concept of setting it up as an inlined call. I'm not sure this will work - I think that you can do sth like .FOO DISPLAY "foo" .BAR DISPLAY "bar" .BAZ PERFORM FOO PERFORM FOO THROUGH BAR where the first PERFORM should just display "foo" but the second should display both "foo" and "bar"? > I think I will give that a shot to see what gets generated. > > Failing that, I will attempt to use LABEL_DECL instead of ASM_EXPR to create > the labels. The suggestion to use LABEL_DECLs instead of symbols was exactly to have a sort-of 1:1 translation of what you have now from the symbol level to debuginfo. Ideally we'd get a better understanding of the COBOL concepts. For example I think we'd want to represent the text area from .FOO to .BAR and from .BAR to .BAZ by a DW_TAG_<...> so we can have a DW_AT_ranges on it. But I also think the 'PERFORM' "statement" needs explicit representation, since there's both a "fallthru" entering of .BAR and a "call-like" entering of .BAR there is no existing DWARF concept to handle such open-coded call sequence you use for PERFORM. Conceptually instead of having a label or symbol at PERFORM the location info could maybe be annotated with a is_perform flag? Or the PERFORM sequence itself (set up return point, jump to X) could be wrapped in a DW_TAG_inlined_subroutine (or a new TAG describing control transfer and "return"). > And in any case, I am about to try eliminating the ASM_EXPR stuff in order > to eliminate this bug. Yes. IMO the least invasive way is to instead use labels. > The labels are in support of GDB, and I can get to that later.
