https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Robert Dubner from comment #20)
> (In reply to Richard Biener from comment #15)
> > (In reply to Robert Dubner from comment #14)
> > > (In reply to Richard Biener from comment #13)
> > > > (In reply to Robert Dubner from comment #7)
> > > >
> [...]
> > There's no good way to create a NOP, but I don't understand why you'd need
> > that.
>
> Consider
> 0100 DISPLAY "this"
> 0101 para-1.
> 0102 DISPLAY "that"
>
> I generate my NOP equivalent at the point of line 101, so that when NEXTing
> through the code GDB stops at line 101, which otherwise generates no code to
> be tagged with ".loc 1 101".
In principle "location views" are supposed to address this, on GIMPLE this
would mean you'd insert a DEBUG BEGIN_STMT. I don't think there's anything
on GENERIC, YMMV with stmts that compile "empty". In principle user
LABEL_DECLs should be preserved and be visible this way.
Oh, but of course no debug consumer (like for example gdb) actually supports
location-views.
The expected behavior in other languages is that such statements (or all
statements elided by the compiler by means of dead code elimination) are
simply "skipped over" when stepping with 'n' ...
> >
> > I'll also note that it's probably worth spending some time thinking about
> > a better DWARF representation than labels and the way to communicate to
> > gdb the desired information. Changing to labels will be quite some work,
> > esp. on the gdb side I'd guess, and the solution still feels a bit of a
> > hack. To me the way COBOL handles PERFORM and specifically the PERFORM
> > "target" feels hacky as well, of course ;)
>
> I wear the description "Your code is hacky" proudly. Yes, it's hacky. I
> can see how, eventually, DWARF will be extended with the DW_AT tags, GCC
> will be extended to handle them, and so will GDB. Meanwhile, I hacked it
> into working.
>
> And I am sheepishly willing to report that my ASM_EXPR hack puts the text
> ".proccallxx" into the symbol table and .debug_info section. I now see that
> I can use LABEL_DECL to, well, put that same text into the symbol table and
> .debug_info section. It's possible that making the switch will not require
> any changes at all to the GDB-COBOL code.
LABEL_DECLs are not in the symbol table, just in .debug_info
