Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GnuCOBOL 3.1: use of COBC_GEN_DUMP_COMMENTS #92

Open
GitMensch opened this issue Nov 4, 2020 · 1 comment
Open

GnuCOBOL 3.1: use of COBC_GEN_DUMP_COMMENTS #92

GitMensch opened this issue Nov 4, 2020 · 1 comment

Comments

@GitMensch
Copy link
Contributor

GitMensch commented Nov 4, 2020

For GnuCOBOL 3.1 we previously could use -fdump to force generation of more fields, even if they aren't directly referenced.
But entries that are related to REDEFINES / level 66 are never part of the dump, level 78 aren't either - and the actual dump on abort may be unwanted (should only be done if the user compiled with those flags).

COBC_GEN_DUMP_COMMENTS solves this by generating everything not requested and the additional fields mentioned above as a C comment, instead of an actual executed code. And it additionally generates information about the fields attributes REDEFINES BASED EXTERNAL GLOBAL ANYLENGTH OCCURS min max [-1 for unbounded] in the dump code:

  cob_dump_field ( 3, "FILLER", COB_SET_FLD(f0, 2, b_26 + 56, &a_1), 0, 0);
  cob_dump_field ( 3, "show", &f_35, 0, 0);
  cob_dump_field ( 1, "extended-infos", &f_36, 0, 0);
  cob_dump_field ( 1, "len-display", &f_39, 0, 0);
  cob_dump_field ( 1, "byte", &f_40, 0, 0);
  /* cob_dump_field ( 1, "byte-redef", &f_41, 0, 0); REDEFINES */
  cob_dump_field ( 1, "hex-tab", COB_SET_FLD(f0, 512, b_42, &a_1), 0, 0);
  /* cob_dump_field ( 1, "hex-tab-red", COB_SET_FLD(f0, 512, b_42, &a_11), 0, 0); REDEFINES */
  {
    /* const int m_1 = 256; */
    {
      /* cob_dump_field ( 3, "hex-vals", &f_44, 0, 1, i_1, 2); OCCURS 1 256 */
    }
  }
  /* cob_dump_field ( 1, "FILLER", COB_SET_FLD(f0, 512, b_42, &a_11), 0, 0); REDEFINES */
  {
    /* const int m_1 = 512; */
    {
      /* cob_dump_field ( 3, "hex-vals512", COB_SET_FLD(f0, 1, b_42, &a_1), 0, 1, i_1, 1); OCCURS 1 512 */
    }
  }
  cob_dump_field (77, "TESTVAR-one", COB_SET_FLD(f0, 3, b_47, &a_13), 0, 0); /* BASED  */
  cob_dump_field (77, "TESTVAR-two", COB_SET_FLD(f0, 12, b_48, &a_14), 0, 0); /* EXTERNAL */
  cob_dump_field (77, "TESTVAR-three", COB_SET_FLD(f0, 42, b_49, &a_1), 0, 0); /* GLOBAL */


  /* Dump LINKAGE SECTION */
  b_50 = last_b_50;
  b_51 = last_b_51;
  cob_dump_output("LINKAGE");
  cob_dump_field ( 1, "buffer", COB_SET_FLD(f0, 1, b_50, &a_1), 0, 0); /* ANYLENGTH */
  cob_dump_field ( 1, "valuelen", COB_SET_FLD(f0, 1, b_51, &a_2), 0, 0); /* ANYLENGTH */

I suggest to:

  • always set COBC_GEN_DUMP_COMMENTS in the process that invokes cobc to generate debug modules
  • adjust this extension's scanner to use as much as possible from this information, this may also help with handling OCCURS support for OCCURS #38

Note: the current GnuCOBOL CI snapshot includes this already, for tests on Windows the CI generated MinGW package can be used.
GnuCOBOL 3.1 final release is expected within the next days.

@GitMensch
Copy link
Contributor Author

As that's were the initial implementation of the "cob_field" variant came from; @brunopacheco1 can you please have a look at this? Always setting this environment variable before calling cobc will do no harm; the actual main adjustment is likely to parse the generated dump part to know about all the fields (instead of primarily searching the header for its definition) and to also do this from the comments).
Note: if we need the knowledge "is that possible": GC 3.1.1 also implements a function to query the version: libcob_version()- if that function is available the extended dump code [possibly as comment only, if -fdump option was not used at compile-time] is also generated - but maybe that's not necessary to know: always export the variable during compile, always look for the code/comment (in the P_dump label), if it isn't there [or always?] fallback to reading the data from the header.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant