gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] gdb support from gcc-cobol


From: Bernard Giroud
Subject: Re: [open-cobol-list] gdb support from gcc-cobol
Date: Wed Jun 4 23:20:03 2003

Keisuke Nishida a écrit :

> At Tue, 03 Jun 2003 21:48:26 +0200,
> Bernard Giroud wrote:
> >
> > > > > struct elem_G
> > > > > {
> > > > >   unsigned char X[2];
> > > > >   unsigned char Y[2];
> > > > > };
> (snip)
> > I agree it is a little more complex, but it is much more
> > natural. Another aspect: this is probably a point of
> > divergence between OC and gcc-cobol (aka Gobol).
>
> Maybe I am missing something, but is there any technical
> advantage of having group items defined as structures?
> Otherwise, I do not see the point of changing the current
> design, which is sufficiently simple.
>
> Keisuke

Taking this example:

01 one-rec.
  05 one-fld1 pic x(2).
  05 one-fld2 pic 9(2) comp.
 (... 200 other fields ...)
  05 one-fldn pic s9(3)v99 comp-3.

Without separate names, you won't have separate symbols
in gdb, and consequently you won't be able to say:
p one-fldn
because we won't have the fact that this field is a comp-3
with 2 decimal places.

Also even you could say p one-rec(2408:3) (assuming
one-fldn is at offset 2408 from the satrt of one-rec,
you have to look at the compiler symbol map to get
the address 2408 :-(((.

That would mean also that you can reference by name
only a few percentage of all fields. In our shop that
would probably be below 5 to 10% :--((((, because
all uninitialized fields are subordinate to a 01 external
for performance reasons.

I hope I convinced you that it must be done; but
I'm ready to help to do it. And would it be easier
to implement the change first in OC, than gobol,
or directly in gobol. I'll have a look in OC to see
how hard it would be (maybe a union for the struct
and the char array?).

--
Bernard Giroud




reply via email to

[Prev in Thread] Current Thread [Next in Thread]