Issue an internal warning on first deprecated function call

Issue an internal warning on first deprecated function call

[Andrew Cagney]

Hello,

The problem behind this was discussed in:
http://sources.redhat.com/ml/gdb/2001-03/msg00227.html

The idea is to issue an internal-warning on the first call to a 
deprecated [multi-arch] function.

The intent is to better alert the user to the possability that their GDB 
is on its last legs.

Thoughts?  Variations on the idea?
Andrew

Re: Issue an internal warning on first deprecated function call

[Kevin Buettner]

On Aug 15,  6:00pm, Andrew Cagney wrote:

> The problem behind this was discussed in:
> http://sources.redhat.com/ml/gdb/2001-03/msg00227.html
> 
> The idea is to issue an internal-warning on the first call to a 
> deprecated [multi-arch] function.
> 
> The intent is to better alert the user to the possability that their GDB 
> is on its last legs.
> 
> Thoughts?  Variations on the idea?

I think we should strive to just fix (eliminate) the calls to
deprecated functions instead.  However, there are times when it's too
hard or can't be sufficiently tested.

A variation on the above idea is to scan a newly created gdbarch
struct to see if any deprecated functions are being used.  If so,
print only one message per session.  (I.e, instead of seeing N
messages from N deprecated function, you'd only see one message for
the whole lot.) The nuisance factor could be cut back even further if
we arrange for .gdbinit setting which can be used to disable such
messages.

This variation will also cause the message to be printed at a more
predictable time, probably either at startup or just after a ``file''
operation.

Kevin

Re: Issue an internal warning on first deprecated function call

[Daniel Jacobowitz]

On Thu, Aug 15, 2002 at 03:33:03PM -0700, Kevin Buettner wrote:
> On Aug 15,  6:00pm, Andrew Cagney wrote:
> 
> > The problem behind this was discussed in:
> > http://sources.redhat.com/ml/gdb/2001-03/msg00227.html
> > 
> > The idea is to issue an internal-warning on the first call to a 
> > deprecated [multi-arch] function.
> > 
> > The intent is to better alert the user to the possability that their GDB 
> > is on its last legs.
> > 
> > Thoughts?  Variations on the idea?
> 
> I think we should strive to just fix (eliminate) the calls to
> deprecated functions instead.  However, there are times when it's too
> hard or can't be sufficiently tested.
> 
> A variation on the above idea is to scan a newly created gdbarch
> struct to see if any deprecated functions are being used.  If so,
> print only one message per session.  (I.e, instead of seeing N
> messages from N deprecated function, you'd only see one message for
> the whole lot.) The nuisance factor could be cut back even further if
> we arrange for .gdbinit setting which can be used to disable such
> messages.
> 
> This variation will also cause the message to be printed at a more
> predictable time, probably either at startup or just after a ``file''
> operation.

I definitely like this idea.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

FYI,

The intent was for only one internal-warning message to appear per debug 
session.  Given that an internal-warning message is pretty 
``on-the-nose'' I don't think I could get away with any more than one.

I wrote:

> > The problem behind this was discussed in:
> > http://sources.redhat.com/ml/gdb/2001-03/msg00227.html

(recommended read)

> > The idea is to issue an internal-warning on the first call to a 
> > deprecated [multi-arch] function.

For architecture methods, it's pretty easy -- hook the 
``set_gdbarch_deprecated...()'' calls.  For things like 
write_register_bytes() it is less so.

enjoy,
Andrew

Re: Issue an internal warning on first deprecated function call

[Carlos O'Donell]

> 
> A variation on the above idea is to scan a newly created gdbarch
> struct to see if any deprecated functions are being used.  If so,
> print only one message per session.  (I.e, instead of seeing N
> messages from N deprecated function, you'd only see one message for
> the whole lot.) The nuisance factor could be cut back even further if
> we arrange for .gdbinit setting which can be used to disable such
> messages.

I like the 'once per session' idea.
Can we make the that message a rather largish banner?

c.

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

> A variation on the above idea is to scan a newly created gdbarch
>> struct to see if any deprecated functions are being used.  If so,
>> print only one message per session.  (I.e, instead of seeing N
>> messages from N deprecated function, you'd only see one message for
>> the whole lot.) The nuisance factor could be cut back even further if
>> we arrange for .gdbinit setting which can be used to disable such
>> messages.
> 
> 
> I like the 'once per session' idea.
> Can we make the that message a rather largish banner?

My intent is for it to use ``internal-warning'' which means it will look 
something like this:

(gdb) maint internal-error
/home/scratch/GDB/src/gdb/maint.c:121: gdb-internal-error: internal 
maintenance
An internal GDB error was detected.  This may make further
debugging unreliable.  Quit this debugging session? (y or n) n

Create a core file containing the current state of GDB? (y or n) n
(gdb)

s/error/warning/

Since the user is going to need to interact with this, they will get 
very annoyed with it pretty quick.  This is why I'm also proposing 
another command for gaging it :-)

I think ``internal-warning'' is correct since there is a very very good 
chance that the deprecated interface will have been [unintentionally] 
broken by the introduction of the new mechanisms.

Andrew

Re: Issue an internal warning on first deprecated function call

[Carlos O'Donell]

> 
> My intent is for it to use ``internal-warning'' which means it will look 
> something like this:
> 

It can stil be a large banner :)

> (gdb) maint internal-error
> /home/scratch/GDB/src/gdb/maint.c:121: gdb-internal-error: internal 
> maintenance
> An internal GDB error was detected.  This may make further
> debugging unreliable.  Quit this debugging session? (y or n) n
> Create a core file containing the current state of GDB? (y or n) n
> (gdb)
> s/error/warning/

Would it be better if the message was more explanatory?
'internal maintenance - deprecated [multi-arch] function call' 

I have this feeling that we will want to make this message as clear
as possible. We want to say "Hey you! Wakeup! Fix it or lose it!"

> Since the user is going to need to interact with this, they will get 
> very annoyed with it pretty quick.  This is why I'm also proposing 
> another command for gaging it :-)

Or submit to the pain and torture that users will inflict on the 
mailing list ;)

> I think ``internal-warning'' is correct since there is a very very good 
> chance that the deprecated interface will have been [unintentionally] 
> broken by the introduction of the new mechanisms.

*nods*

c.

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

>> (gdb) maint internal-error
>> /home/scratch/GDB/src/gdb/maint.c:121: gdb-internal-error: internal 
>> maintenance
>> An internal GDB error was detected.  This may make further
>> debugging unreliable.  Quit this debugging session? (y or n) n
>> Create a core file containing the current state of GDB? (y or n) n
>> (gdb)
>> s/error/warning/
> 
> 
> Would it be better if the message was more explanatory?
> 'internal maintenance - deprecated [multi-arch] function call' 
> 
> I have this feeling that we will want to make this message as clear
> as possible. We want to say "Hey you! Wakeup! Fix it or lose it!"

Yes, definitly, the above was just to illustrate the interaction.

Andrew

Re: Issue an internal warning on first deprecated function call

[Eli Zaretskii]

> Date: Fri, 16 Aug 2002 09:50:07 -0400
> From: Andrew Cagney <ac131313@ges.redhat.com>
> 
> (gdb) maint internal-error
> /home/scratch/GDB/src/gdb/maint.c:121: gdb-internal-error: internal 
> maintenance
> An internal GDB error was detected.  This may make further
> debugging unreliable.  Quit this debugging session? (y or n) n
> 
> Create a core file containing the current state of GDB? (y or n) n
> (gdb)
> 
> s/error/warning/
> 
> Since the user is going to need to interact with this, they will get 
> very annoyed with it pretty quick.

Yes, I think users will get annoyed and even scared.  The message is
meant for the port maintainers, not for users.

> This is why I'm also proposing another command for gaging it :-)

But that won't help, since most users will wtill see the message
until they gag it.

I like Kevin's suggestion better.

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

>> Date: Fri, 16 Aug 2002 09:50:07 -0400
>> From: Andrew Cagney <ac131313@ges.redhat.com>
>> 
>> (gdb) maint internal-error
>> /home/scratch/GDB/src/gdb/maint.c:121: gdb-internal-error: internal 
>> maintenance
>> An internal GDB error was detected.  This may make further
>> debugging unreliable.  Quit this debugging session? (y or n) n
>> 
>> Create a core file containing the current state of GDB? (y or n) n
>> (gdb)
>> 
>> s/error/warning/
>> 
>> Since the user is going to need to interact with this, they will get 
>> very annoyed with it pretty quick.
> 
> 
> Yes, I think users will get annoyed and even scared.  The message is
> meant for the port maintainers, not for users.

Another option is, by default, have the message disabled.  Only enable 
it when in say maintainer-mode or while running the testsuite.

>> This is why I'm also proposing another command for gaging it :-)
> 
> 
> But that won't help, since most users will wtill see the message
> until they gag it.
> 
> I like Kevin's suggestion better.

My intent was for the message to only appear once.

enjoy,
Andrew

Re: Issue an internal warning on first deprecated function call

[Carlos O'Donell]

ac,

> >
> >Yes, I think users will get annoyed and even scared.  The message is
> >meant for the port maintainers, not for users.
> 
> Another option is, by default, have the message disabled.  Only enable 
> it when in say maintainer-mode or while running the testsuite.
> 

What's wrong with making users scared? Isn't that the purpose of 
the message? What if there are no port maintainers?

Leave it enabled by default... raise awarness :)

c.

Re: Issue an internal warning on first deprecated function call

[Eli Zaretskii]

> Date: Tue, 20 Aug 2002 09:17:25 -0400
> From: "Carlos O'Donell" <carlos@baldric.uwo.ca>
> 
> What's wrong with making users scared?

It's wrong because GDB users cannot do anything about the problem, and
the message's language seems to imply it's a potentially very grave
problem (which it isn't).

> What if there are no port maintainers?

Then the head maintainer gets the honor.

Re: Issue an internal warning on first deprecated function call

[Carlos O'Donell]

> > 
> > What's wrong with making users scared?
> 
> It's wrong because GDB users cannot do anything about the problem, and
> the message's language seems to imply it's a potentially very grave
> problem (which it isn't).
> 

It's not a grave problem? Please explain.

> > What if there are no port maintainers?
> Then the head maintainer gets the honor.

Like the parisc port?

c.

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

>> > 
>> > What's wrong with making users scared?
> 
>> 
>> It's wrong because GDB users cannot do anything about the problem, and
>> the message's language seems to imply it's a potentially very grave
>> problem (which it isn't).
>> 
> 
> 
> It's not a grave problem? Please explain.

Eli's right here.  The warning would be to strong.

internal-error and internal-warning refer to GDB detecting an errenous 
internal state.  Error for non-recoverable, warning for recoverable.

Unless some action is taken, the long term prognosis doesn't look good. 
  However, short term, GDB could just as easily die due to a SIGSEG.

>> > What if there are no port maintainers?
> 
>> Then the head maintainer gets the honor.
> 
> 
> Like the parisc port?

Yep.  I get to ``fix'' the problem.

I just checked in a change to MAINTAINERS file so that it recommends 
hppa-elf as the target to try building.  This new target doesn't include 
som support (unlike hppa natives) and so makes the multi-arch task just 
that bit more feasible :-)

enjoy,
Andrew

Re: Issue an internal warning on first deprecated function call

[Kevin Buettner]

On Aug 21, 11:21am, Andrew Cagney wrote:

> > It's not a grave problem? Please explain.
> 
> Eli's right here.  The warning would be to strong.
> 
> internal-error and internal-warning refer to GDB detecting an errenous 
> internal state.  Error for non-recoverable, warning for recoverable.
> 
> Unless some action is taken, the long term prognosis doesn't look good. 

Wait a moment...  You were going to use internal warnings to alert the
users that a deprecated function has been called, right?  I don't
consider this to be an erroneous internal state that has to be
recovered from.

>   However, short term, GDB could just as easily die due to a SIGSEG.

It shouldn't so long as the gdb developers haven't broken the legacy
functions that are being deprecated.  (Unless it did before, but that's
a different problem.)

Kevin

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

> On Aug 21, 11:21am, Andrew Cagney wrote:
> 
> 
>> > It's not a grave problem? Please explain.
> 
>> 
>> Eli's right here.  The warning would be to strong.
>> 
>> internal-error and internal-warning refer to GDB detecting an errenous 
>> internal state.  Error for non-recoverable, warning for recoverable.
>> 
>> Unless some action is taken, the long term prognosis doesn't look good. 
> 
> 
> Wait a moment...  You were going to use internal warnings to alert the
> users that a deprecated function has been called, right?  I don't
> consider this to be an erroneous internal state that has to be
> recovered from.

I originally proposed that, but per above, I'm dropping the idea.

>>   However, short term, GDB could just as easily die due to a SIGSEG.
> 
> 
> It shouldn't so long as the gdb developers haven't broken the legacy
> functions that are being deprecated.  (Unless it did before, but that's
> a different problem.)
> 
> Kevin
> 

Re: Issue an internal warning on first deprecated function call

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:

Andrew> The idea is to issue an internal-warning on the first call to a
Andrew> deprecated [multi-arch] function.

Andrew> Thoughts?  Variations on the idea?

What about marking functions as deprecated at compile time using
__attribute__?  Then the burden falls on the maintainers not to call
deprecated functions.  (I'm not certain that
__attribute__((deprecated)) works if you are calling through a
function pointer.)

Tom

Re: Issue an internal warning on first deprecated function call

[Eli Zaretskii]

> Date: Wed, 21 Aug 2002 09:05:08 -0400
> From: "Carlos O'Donell" <carlos@baldric.uwo.ca>
> 
> > > What's wrong with making users scared?
> > 
> > It's wrong because GDB users cannot do anything about the problem, and
> > the message's language seems to imply it's a potentially very grave
> > problem (which it isn't).
> 
> It's not a grave problem? Please explain.

The warning was being considered for the case when GDB calls a
deprecated function.  As long as the deprecated function does its job,
a GDB user doesn't care about it being called.  We certainly should
not scare users in this case telling them something like "GDB will
likely crash in a moment; you HAVE been warned!".

Re: Issue an internal warning on first deprecated function call

[Carlos O'Donell]

On Thu, Aug 22, 2002 at 10:51:02AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 21 Aug 2002 09:05:08 -0400
> > From: "Carlos O'Donell" <carlos@baldric.uwo.ca>
> > 
> > > > What's wrong with making users scared?
> > > 
> > > It's wrong because GDB users cannot do anything about the problem, and
> > > the message's language seems to imply it's a potentially very grave
> > > problem (which it isn't).
> > 
> > It's not a grave problem? Please explain.
> 
> The warning was being considered for the case when GDB calls a
> deprecated function.  As long as the deprecated function does its job,
> a GDB user doesn't care about it being called.  We certainly should
> not scare users in this case telling them something like "GDB will
> likely crash in a moment; you HAVE been warned!".

I apologize for finding it hard to track a true line between gdb-user 
and gdb-developer ;-) 

c.

Re: Issue an internal warning on first deprecated function call

[Andrew Cagney]

>>>>>> "Andrew" == Andrew Cagney <ac131313@ges.redhat.com> writes:
> 
> 
> Andrew> The idea is to issue an internal-warning on the first call to a
> Andrew> deprecated [multi-arch] function.
> 
> Andrew> Thoughts?  Variations on the idea?
> 
> What about marking functions as deprecated at compile time using
> __attribute__?  Then the burden falls on the maintainers not to call
> deprecated functions.  (I'm not certain that
> __attribute__((deprecated)) works if you are calling through a
> function pointer.)

Hmm, thanks.  I thought there was such an attribute but couldn't find it 
in the version of the doco I was looking at.  I'll try to check it out.

thanks,
Andrew