Re: Ada's formats

Re: Ada's formats

[Paul Hilfinger]

Andrew,

You wrote:
> Can "we" (I hate this abuse of the Queens English) delete the existing, 
> broken code then? With that resolved, its possible to move onto the next 
> Ada problem. 

Joel wrote:
> Could you explain which part of the code you're refering to? 

You then wrote:
> Uses of the struct language_format_info in core GDB (which 
> translates to local_.*_format macros). Rip that out and I suspect that 
> you'll find adding ada's formatting using method rather than 
> printf formats is trivial.

I've finally been able to look at this seriously, and am
afraid we're still not clear on what is "broken" that needs fixing.
AFAICS, the language_format_info approach generally works in a purely
functional sense, and back when we (briefly) used it to apply Ada's
language formats for hex and octal strings, it worked just fine for
us.  (Currently, I see that m2-lang.c and scm-lang.c use non-C-like
values for their language_format_info entries; is the mechanism working for 
them?)

So I am assuming that you are referring mainly to a bogosity in the
design aesthetics.  I am willing to do the necessary cleanup here as
community service, even though we have no need of it for the Ada
language module, but first I would like to make quite sure I have a
clear picture of what your idea of the right solution is.  Is it
simply a matter of replacing the language_format_info format strings
with functions, or did you have something else entirely in mind?

Paul

Re: Ada's formats

[Andrew Cagney]

> Andrew,
> 
> You wrote:
> 
>>> Can "we" (I hate this abuse of the Queens English) delete the existing, 
>>> broken code then? With that resolved, its possible to move onto the next 
>>> Ada problem. 
> 
> 
> Joel wrote:
> 
>>> Could you explain which part of the code you're refering to? 
> 
> 
> You then wrote:
> 
>>> Uses of the struct language_format_info in core GDB (which 
>>> translates to local_.*_format macros). Rip that out and I suspect that 
>>> you'll find adding ada's formatting using method rather than 
>>> printf formats is trivial.
> 
> 
> I've finally been able to look at this seriously, and am
> afraid we're still not clear on what is "broken" that needs fixing.
> AFAICS, the language_format_info approach generally works in a purely
> functional sense, and back when we (briefly) used it to apply Ada's
> language formats for hex and octal strings, it worked just fine for
> us.  (Currently, I see that m2-lang.c and scm-lang.c use non-C-like
> values for their language_format_info entries; is the mechanism working for 
> them?)

I was asking if we should even support the feature of being able to 
print values in a language specific way.  Or to approach this from 
another angle, in addition to supporting cut'n'paste of source code 
expressions into GDB, should we support cut'n'paste of GDB's output 
values into the source code?

The conclusion was a resounding ``maybe''.

Knowing that m2 is effectively dead, and that JimB (the ex Scheme 
maintainer) was recommending scm's removal, this leaves us with ``maybe 
useful'' (read dead) code (well unless that ``maybe'' gets upgraded to a 
``yes'' :-).

Also knowing that the code is problematic (grep for 32x64), this tells 
us that it's time to cut our losses.

> So I am assuming that you are referring mainly to a bogosity in the
> design aesthetics.  I am willing to do the necessary cleanup here as
> community service, even though we have no need of it for the Ada
> language module, but first I would like to make quite sure I have a
> clear picture of what your idea of the right solution is.  Is it
> simply a matter of replacing the language_format_info format strings
> with functions, or did you have something else entirely in mind?

If you're willing to overhaul the code in that way, and then use it for 
Ada, would be very much appreciated!  I was putting forward that the 
code simply be removed.

enjoy,
Andrew

Re: Ada's formats

[Paul Hilfinger]

Andrew,

I have a patch that removes all the language-specific numeric formatting.  
It does indeed clean things up a good deal.  There were only three 
uses of language-specific numeric printing: for scm-lang.c, m2-lang.c, and
p-lang.c.  You indicated that the first two were obsolescent and therefore
irrelevant.  What's the story with Pascal?  

Paul Hilfinger

Re: Ada's formats

[Paul Hilfinger]

> I looked at the pascal specifics:
> 
> the only real difference is that the hexadecimal number
> are printed as $ab34 instead of 0xab34 for C language,
> but I remember that I got some comments that I
> should remove this because the parser does not support
> the parsing of $ab34 as a hexadecimal number, as this would
> interfere with the gdb variables...

There is one other discrepancy in Pascal: it specifies something for the
binary format as well:

 {"", "%", "b", ""},		/* Binary format info */

as opposed to C's

  {"", "", "", ""},		/* Binary format info */

Pascal appears to be the only language that uses something other than this
latter format for binary.

Paul

Re: Ada's formats

[Andrew Cagney]

> Andrew,
> 
> I have a patch that removes all the language-specific numeric formatting.  
> It does indeed clean things up a good deal.  There were only three 
> uses of language-specific numeric printing: for scm-lang.c, m2-lang.c, and
> p-lang.c.  You indicated that the first two were obsolescent and therefore
> irrelevant.  What's the story with Pascal?  

It turns out [unfortunatly off list discussion] that for pascal there's 
an outstanding request to disable this feature anyway!

For the feature to ``work'', GDB must be capable of both correctly 
printing, and correctly parsing the natural language values and for 
Pascal that's not possible ($<hex> clashes with $<register>).

We can go ahead with this change,

Andrew

Re: Ada's formats

[Paul Hilfinger]

> > Andrew,
> > 
> > I have a patch that removes all the language-specific numeric formatting.  
> > It does indeed clean things up a good deal.  There were only three 
> > uses of language-specific numeric printing: for scm-lang.c, m2-lang.c, and
> > p-lang.c.  You indicated that the first two were obsolescent and therefore
> > irrelevant.  What's the story with Pascal?  
> 
> It turns out [unfortunatly off list discussion] that for pascal there's 
> an outstanding request to disable this feature anyway!
> 
> For the feature to ``work'', GDB must be capable of both correctly 
> printing, and correctly parsing the natural language values and for 
> Pascal that's not possible ($<hex> clashes with $<register>).
> 
> We can go ahead with this change,
> 
> Andrew
> 



OK.  I'll update and submit the patch.

Paul

Re: Ada's formats

[Andrew Cagney]

>>Can "we" (I hate this abuse of the Queens English) delete the existing, 
>>> broken code then?  With that resolved, its possible to move onto the 
>>> next Ada problem.
> 
> 
> Could you explain which part of the code you're refering to?

Uses of the struct language_format_info in core GDB (which translates to 
local_.*_format macros).  Rip that out and I suspect that you'll find 
adding ada's formatting using method rather than printf formats is trivial.

Andrew

Re: Ada's formats

[Joel Brobecker]

> Can "we" (I hate this abuse of the Queens English) delete the existing, 
> broken code then?  With that resolved, its possible to move onto the 
> next Ada problem.

Could you explain which part of the code you're refering to?

-- 
Joel

Re: Ada's formats

[Andrew Cagney]

>>I'm not talking about GDB, and not Ada here.  Shall _GDB_ support the 
>>> feature of language specific numeric formatting?
> 
> 
> In my opinion, that would be nice.

Can "we" (I hate this abuse of the Queens English) delete the existing, 
broken code then?  With that resolved, its possible to move onto the 
next Ada problem.

Andrew

Re: Ada's formats

[Joel Brobecker]

> I'm not talking about GDB, and not Ada here.  Shall _GDB_ support the 
> feature of language specific numeric formatting?

In my opinion, that would be nice.

-- 
Joel

Re: Ada's formats

[Andrew Cagney]

>>How about this: shall gdb support the feature of language specific 
>>> numeric formatting?
> 
> 
> For the moment, this is not a priority for us. So I am going to delete
> that code, per your suggestion. A patch is coming up.

I'm not talking about GDB, and not Ada here.  Shall _GDB_ support the 
feature of language specific numeric formatting?

Andrew

Re: Ada's formats

[Joel Brobecker]

> How about this: shall gdb support the feature of language specific 
> numeric formatting?

For the moment, this is not a priority for us. So I am going to delete
that code, per your suggestion. A patch is coming up.

-- 
Joel

Re: Ada's formats

[Andrew Cagney]

> Andrew,
> 
> 
>>> #if 0
>>>    {"8#%lo#", "8#", "o", "#"},   /* Octal format info */
>>>    {"%ld", "", "d", ""},         /* Decimal format info */
>>>    {"16#%lx#", "16#", "x", "#"}, /* Hex format info */
>>> #else
>>>    /* Copied from c-lang.c.  */
>>>    {"0%lo", "0", "o", ""},       /* Octal format info */
>>>    {"%ld", "", "d", ""},         /* Decimal format info */
>>>    {"0x%lx", "0x", "x", ""},     /* Hex format info */
>>> #endif
> 
> 
> The problem reflected by the conditionalization here was aesthetic
> internal disagreement as to whether we wanted Ada's literal format for
> hex numbers (e.g., 16#deadbeef#) or C's.  GDB sometimes refers to the
> language vector and sometimes does not, so that if our purpose was to
> be kind to the hypothetical GNAT user (i.e., one who believes that "C"
> is just the third letter of the alphabet), we would not only fail, but
> perhaps sow further confusion.  The two options remain in the source
> code, however, to indicate the embarrassing fact that we are not of
> one mind on the issue.

> If on the other hand you are asking whether I think that (in general),
> it would improve the abstraction to "functionalize" this part of the
> language vector, my answer is a firm ... could be.

How about this: shall gdb support the feature of language specific 
numeric formatting?

If yes, we'll need to make this work.  The current code isn't sufficient 
so a change such as I suggest will be needed.

If no, we should delete all that broken code - it isn't sufficient to 
handle the Ada case.

Here ``could be'' isn't an option :-)

Andrew

Re: Ada's formats

[Paul Hilfinger]

Andrew,

> #if 0
>    {"8#%lo#", "8#", "o", "#"},   /* Octal format info */
>    {"%ld", "", "d", ""},         /* Decimal format info */
>    {"16#%lx#", "16#", "x", "#"}, /* Hex format info */
> #else
>    /* Copied from c-lang.c.  */
>    {"0%lo", "0", "o", ""},       /* Octal format info */
>    {"%ld", "", "d", ""},         /* Decimal format info */
>    {"0x%lx", "0x", "x", ""},     /* Hex format info */
> #endif

The problem reflected by the conditionalization here was aesthetic
internal disagreement as to whether we wanted Ada's literal format for
hex numbers (e.g., 16#deadbeef#) or C's.  GDB sometimes refers to the
language vector and sometimes does not, so that if our purpose was to
be kind to the hypothetical GNAT user (i.e., one who believes that "C"
is just the third letter of the alphabet), we would not only fail, but
perhaps sow further confusion.  The two options remain in the source
code, however, to indicate the embarrassing fact that we are not of
one mind on the issue.

If on the other hand you are asking whether I think that (in general),
it would improve the abstraction to "functionalize" this part of the
language vector, my answer is a firm ... could be.

Paul

Ada's formats

[Andrew Cagney]

Joel, Paul, I'm looking at this:

#if 0
   {"8#%lo#", "8#", "o", "#"},   /* Octal format info */
   {"%ld", "", "d", ""},         /* Decimal format info */
   {"16#%lx#", "16#", "x", "#"}, /* Hex format info */
#else
   /* Copied from c-lang.c.  */
   {"0%lo", "0", "o", ""},       /* Octal format info */
   {"%ld", "", "d", ""},         /* Decimal format info */
   {"0x%lx", "0x", "x", ""},     /* Hex format info */
#endif

Would replacing the printf formats with ada specific functions similar 
to paddr, paddr_nz et.al. or even a single function with multiple 
parameters solve this problem?

Andrew