Re: Merging manuals (was Re: How do you use GDB to debug GDB)

Re: Merging manuals (was Re: How do you use GDB to debug GDB)

[Michael Elizabeth Chastain]

Another argument for separation of gdb.texinfo and gdbint.texinfo:

gdb.texinfo is in some sense a public interface which is meant to be
stable.  But information in gdbint.texinfo is not a public interface
and can change at any moment.

For example, someone could re-implement the symbol table with tries
instead of hash tables (I would really like this!).  That would affect
gdbint.texinfo, but it would not affect gdb.texinfo.

Maybe "public"/"private" are not the right words but there is a
definite difference here.

Michael

Re: Merging manuals (was Re: How do you use GDB to debug GDB)

[Eli Zaretskii]

On Tue, 20 Mar 2001, Michael Elizabeth Chastain wrote:

> gdb.texinfo is in some sense a public interface which is meant to be
> stable.  But information in gdbint.texinfo is not a public interface
> and can change at any moment.

As Andrew says, ``humor me''.

IMHO, we have a looong way to go before we could claim that any of our
documents are complete enough to make the interface stability
consideration enter our radar screens.  Try to diff gdb.texinfo from
v5.0 against the current version and see for yourself: it's still very
much in a fluid phase.  And rightly so: we still have a lot to do to
to make it exhaustive and well-indexed (I'm still finding myself
looking for index entries that aren't there too often).

> For example, someone could re-implement the symbol table with tries
> instead of hash tables (I would really like this!).  That would affect
> gdbint.texinfo, but it would not affect gdb.texinfo.

I'd be happy if I could assume such reimplementation will be
documented as part of the redesign; right now, most changes are not
accompanied with documentation.  Heck, I'd be happy if the _current_
design of symbol tables were documented.  While Michael happened to
pick up one of the more documented aspects of GDB internals, even
symtabs docs leaves a lot to be desired.  For example, minsyms are not
documented at all.

In other words, there are more omissions in gdbint.texinfo than there
is information.  I don't think the rate of change matters, given this.

Re: Merging manuals (was Re: How do you use GDB to debug GDB)

[J.T. Conklin]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
Eli> On Tue, 20 Mar 2001, Michael Elizabeth Chastain wrote:

>> gdb.texinfo is in some sense a public interface which is meant to be
>> stable.  But information in gdbint.texinfo is not a public interface
>> and can change at any moment.

Eli> As Andrew says, ``humor me''.

Wouldn't Andrew say ``humour me'' :-)

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: Merging manuals (was Re: How do you use GDB to debug GDB)

[Kevin Buettner]

On Mar 20, 12:16pm, Michael Elizabeth Chastain wrote:

> Another argument for separation of gdb.texinfo and gdbint.texinfo:
> 
> gdb.texinfo is in some sense a public interface which is meant to be
> stable.  But information in gdbint.texinfo is not a public interface
> and can change at any moment.

I find Michael's argument compelling.  I think the manuals should be
kept separate.

Kevin

Re: Merging manuals (was Re: How do you use GDB to debug GDB)

[Fernando Nasser]

Kevin Buettner wrote:
> 
> On Mar 20, 12:16pm, Michael Elizabeth Chastain wrote:
> 
> > Another argument for separation of gdb.texinfo and gdbint.texinfo:
> >
> > gdb.texinfo is in some sense a public interface which is meant to be
> > stable.  But information in gdbint.texinfo is not a public interface
> > and can change at any moment.
> 
> I find Michael's argument compelling.  I think the manuals should be
> kept separate.
> 

So do I.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

GCC is depreciating multi-line strings

[Stephen Smith]

I don't know if the maintainers on this list have been following the discussion on the gcc mailing list regarding
multiline strings being depreciated.

All I know is that while I have been perusing the code looking for where to add my hook, for managing shared libraries
using the remote protocol,
I have seen quite a few.

Just wanted you all to know.

sps

Re: GCC is depreciating multi-line strings

[Andrew Cagney]

Um, I'm slightly confused.  What exactly is ment by multi-line strings? 
I've found this link and am still looking :-)

http://gcc.gnu.org/ml/gcc/2001-03/msg00855.html

	Andrew

Re: GCC is depreciating multi-line strings

[Andrew Cagney]

Andrew Cagney wrote:
> 
> Um, I'm slightly confused.  What exactly is ment by multi-line strings?
> I've found this link and am still looking :-)
> 
> http://gcc.gnu.org/ml/gcc/2001-03/msg00855.html

Ok, there are the following:

   illegal:

	"blah
	blah"

    k&r

	"blah\n\
	blah"

    iso-c

	"blah\n"
	"blah"

GDB should only be using the latter two with new code prefering the last
one.  I think, for the most part, it is.  Code using the first can
obviously be fixed :-)

	Andrew

Re: GCC is depreciating multi-line strings

[Christopher Faylor]

On Tue, Mar 20, 2001 at 06:04:47PM -0500, Andrew Cagney wrote:
>Um, I'm slightly confused.  What exactly is ment by multi-line strings? 
>I've found this link and am still looking :-)
>
> http://gcc.gnu.org/ml/gcc/2001-03/msg00855.html

Cygwin has been bit by this recent change.

a = "This is
the multiline string
that has been deprecated.";

gcc stores that as three separate lines.

The "correct" way to do this is:

a = "This is\n\
the multiline string\n\
which has not been deprecated.";

This is also ok, of course:

a = "abc\
def";

It is equivalent to:

a = "abcdef";

The reason for deprecating the non \ usage is that it is not portable.

If gdb uses this construct, I have a hard time believing that this could
be true.

A quick grep seems to show that gdb is doing the right thing so I really
don't think that this is an issue.

cgf

Re: Merging manuals (was Re: How do you use GDB to debug GDB)

[Andrew Cagney]

Michael Elizabeth Chastain wrote:
> 
> Another argument for separation of gdb.texinfo and gdbint.texinfo:
> 
> gdb.texinfo is in some sense a public interface which is meant to be
> stable.  But information in gdbint.texinfo is not a public interface
> and can change at any moment.
> 
> For example, someone could re-implement the symbol table with tries
> instead of hash tables (I would really like this!).  That would affect
> gdbint.texinfo, but it would not affect gdb.texinfo.

Kind of.

GDB's user guide changes (well should also) as GDB evolves. That is
because the ``public'' interface isn't frozen, changing between
releases.

The reason for making it all part of the one mega document is that it
would stop us sticking our head in the sand and ignore the fact that
half of it is now crap^D^D^D^D out of date :-/

For what it is worth, I don't really care.  I just know what one of the
5.1 tick items is.

	enjoy,
		Andrew