[rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

Hello,

Following up the thread on gdb@sources, this introduces an 
INTEGER_TO_ADDRESS() method which both the d10v and the MIPS use.

Since JimB gave a very good explination as to the problems it has and a 
guideline to its use, I included that at the point it is used.  I think 
including ``pragmatics'' such as that is a good thing.  The other 
possability is to add it to the doco.

The only thing I'm not sure about is the name.  The type of the input 
parameter isn't necessary an integer.  The name reflecting more the 
intent that the target first convert it to an integer and then to an 
address.

Andrew
From vinschen@redhat.com Tue Sep 25 14:54:00 2001
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches <gdb-patches@sources.redhat.com>
Subject: Re: [PATCH]: testsuite/gdb.base/constvars.exp
Date: Tue, 25 Sep 2001 14:54:00 -0000
Message-id: <20010925235356.P29024@cygbert.vinschen.de>
References: <20010925192434.M29024@cygbert.vinschen.de> <3BB0C224.AB324D56@cygnus.com> <3BB0CB81.8385E123@redhat.com> <3BB0F122.3E45B3ED@cygnus.com>
X-SW-Source: 2001-09/msg00338.html
Content-length: 1584

On Tue, Sep 25, 2001 at 02:03:30PM -0700, Michael Snyder wrote:
> Fernando Nasser wrote:
> > 
> > Michael Snyder wrote:
> > >
> > > Corinna Vinschen wrote:
> > > >
> > > > Hi,
> > > >
> > > > I patched the test constvars.exp to get rid of the $gcc_compiled
> > > > compile dependencies which result in XFAIL behaviour when the
> > > > tests are compiled with GCC.  AFAICS, they aren't needed if just
> > > > the tests are more correct.
> > > >
> > > > E.g., the testsuite expects strings like "unsigned long" while
> > > > gdb may also emit "long unsigned" or "long unsigned int".
> > > >
> > > > The below patch cares for that.
> > > >
> > > > Corinna
> > >
> > > The test was originally submitted by HP, and probably
> > > worked only with the HP compiler.  I like the idea of
> > > extending itto work with GCC, but I wonder -- will this
> > > work with stabs?  Or only with dwarf?
> > >
> > > And if it won't work with stabs -- do we care?
> > >
> > 
> > Can someone please help us and try it with stabs?
> 
> OK, I've tried it.  Alas, it does not work.  And native Linux
> still uses stabs, so that means we care.  ;-(  Sorry, Corinna.
> It's a good change, but we need some kind of test that applies
> the xfails for stabs and not for dwarf.
> 
> In the meantime, if you want to just check in the regular expression
> changes, I'm sure that would be OK -- it would preserve your work.

What I don't understand is why it's coupled to `gcc_compiled'
while it's in reality target dependend.

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

> Hello,
> 
> Following up the thread on gdb@sources, this introduces an INTEGER_TO_ADDRESS() method which both the d10v and the MIPS use.
> 
> Since JimB gave a very good explination as to the problems it has and a guideline to its use, I included that at the point it is used.  I think including ``pragmatics'' such as that is a good thing.  The other possability is to add it to the doco.
> 
> The only thing I'm not sure about is the name.  The type of the input parameter isn't necessary an integer.  The name reflecting more the intent that the target first convert it to an integer and then to an address.
> 

Attached is a revised patch.  I've also added a pragmatics section to 
the relevant documentation.

Comments (on the doco?).

Andrew

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Eli Zaretskii]

> Date: Mon, 01 Oct 2001 15:55:46 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Attached is a revised patch.  I've also added a pragmatics section to 
> the relevant documentation.

Approved, with these minor corrections:

> + @item INTEGER_TO_ADDRESS (@var{type}, @var{buf})
> + @findex INTEGER_TO_ADDRESS

I suggest "@cindex converting integers to addresses" here.

> + compiler does.  When the user copies a well defined expression from
> + their source code and hand it to a @code{print} command, they should get
> + the same value as would have been computed by the target program.

Since most of this sentence is in plural, I think it should start with
"When the users copy".

> + needs to be justified carefully.  In other words, GDB doesn't really
> + have the freedom to do these conversions in clever and useful ways. It
> + has, however, been pointed out that users aren't complaining about how
> + GDB casts integers to pointers; they are complaining that they can't

"GDB" should be "@value{GDBN}".

> + Adding an architecture method like @code{INTEGER_TO_ADDRESS} certainly
> + makes it possible for GDB to "get it right" in all circumstances.}

Texinfo sources should use `` and '' instead of " for quoting.

There's also at least one place with a single space between two
sentences.

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

> Since most of this sentence is in plural, I think it should start with
> "When the users copy".


Hmm, I changed it all to single.  Along with the other tweeks I ended up 
with:

+
+ @item INTEGER_TO_ADDRESS (@var{type}, @var{buf})
+ @findex INTEGER_TO_ADDRESS
+ @cindex converting integers to addresses
+ Define this when the architecture needs to handle non-pointer to address
+ conversions specially.  Converts that value to an address according to
+ the current architectures conventions.
+
+ @emph{Pragmatics: When the user copies a well defined expression from
+ their source code and pass it, as a parameter, to @value{GDBN}'s
+ @code{print} command, they should get the same value as would have been
+ computed by the target program.  Any deviation from this rule can cause
+ major confusion and annoyance, and needs to be justified carefully.  In
+ other words, @value{GDBN} doesn't really have the freedom to do these
+ conversions in clever and useful ways.  It has, however, been pointed
+ out that users aren't complaining about how @value{GDBN} casts integers
+ to pointers; they are complaining that they can't take an address from a
+ disassembly listing and give it to @code{x/i}.  Adding an architecture
+ method like @code{INTEGER_TO_ADDRESS} certainly makes it possible for
+ @value{GDBN} to ``get it right'' in all circumstances.}
+
+ @xref{Target Architecture Definition, , Pointers Are Not Always
+ Addresses}.

hope its right,

Andrew

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Eli Zaretskii]

> Date: Wed, 03 Oct 2001 16:29:15 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> > Since most of this sentence is in plural, I think it should start with
> > "When the users copy".
> 
> Hmm, I changed it all to single.

You did?

> + @emph{Pragmatics: When the user copies a well defined expression from
> + their source code and pass it, as a parameter, to @value{GDBN}'s
> + @code{print} command, they should get the same value as would have been
> + computed by the target program.

Here "When the user copies" is single, but the rest of the sentence
says "their source", "pass it", and "they should get", which are all
plural.  To my ear this sounds wrong, but that's just me.

> hope its right,

Apart of that small nit, it is.

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

> 
> Here "When the user copies" is single, but the rest of the sentence
> says "their source", "pass it", and "they should get", which are all
> plural.  To my ear this sounds wrong, but that's just me.

It is likely gender neutral australian. I'm going to do some digging.

Andrew

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

> 
> Here "When the user copies" is single, but the rest of the sentence
> says "their source", "pass it", and "they should get", which are all
> plural.  To my ear this sounds wrong, but that's just me.
> 
> It is likely gender neutral australian. I'm going to do some digging.


Checking http://www.dict.mq.edu.au/ and searching for ``their'' and 
``they'' I've found:


their

determiner 1. the possessive form of they. 2.  (used with singular force 
in informal contexts, and increasingly in formal contexts, in place of a 
gender-specific form when the sex of the antecedent is not determined): 
who has left their pen on my desk? [Middle English, from Scandinavian]
Usage: See note at they.


they

pronoun (personal) third person, plural, subjective (them) 1. plural of 
he, she, and it. 2. people in general: they say he is rich. 3.  (used 
with singular force in informal contexts, and increasingly in formal 
contexts, in place of a gender-specific form where the sex of the 
antecedent is not determined): if anybody cheats they will be 
disqualified. [Middle English; from Scandinavian]
Usage: The use of they, them, and their as non-gender-specific singulars 
(as in a doctor and their patients) has always had currency in spoken 
English and is now increasingly accepted in written English. This use of 
they gives rise to the form themself for the reflexive pronoun by 
analogy with myself, himself, etc.


enjoy,
Andrew

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Martin M. Hunt]

On Wednesday 03 October 2001 11:10 pm, Eli Zaretskii wrote:
> > Date: Wed, 03 Oct 2001 16:29:15 -0400
> > From: Andrew Cagney <ac131313@cygnus.com>
> >
> > > Since most of this sentence is in plural, I think it should start with
> > > "When the users copy".
> >
> > Hmm, I changed it all to single.
>
> You did?
>
> > + @emph{Pragmatics: When the user copies a well defined expression from
> > + their source code and pass it, as a parameter, to @value{GDBN}'s
> > + @code{print} command, they should get the same value as would have been
> > + computed by the target program.
>
> Here "When the user copies" is single, but the rest of the sentence
> says "their source", "pass it", and "they should get", which are all
> plural.  To my ear this sounds wrong, but that's just me.

It is wrong.  "pass" must be "passes" to match the singular "user".

"their" is singular in this context and has been used as a gender-neutral 
pronoun for at least 500 years. Likewise "they" is singular in this context.

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

> 
> It is wrong.  "pass" must be "passes" to match the singular "user".

I'll fix this.  Thanks.

> "their" is singular in this context and has been used as a gender-neutral 
> pronoun for at least 500 years. Likewise "they" is singular in this context.

This is more interesting.  While it has been in common (spoken) use for 
500 years, acceptance of the written / formal form appears to only 
recently have gained some form of offical acceptance.  Macquarie (OZ) 
was explicit on this, Oxford (CA) was more vague.  I should probably try 
to check Webester's new speak.

Anyway, we're all speaking / writing Strine, eh?

enjoy,
Andrew

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Frank Ch. Eigler]

cagney wrote:

: [...]
: Anyway, we're all speaking / writing Strine, eh?

Don't believe him: he should be speaking Canuck by now, eh?


- FChE

Re: [rfc/rfa:doc] INTEGER_TO_ADDRESS; Was: INTEGER_TO_ADDRESS(), thoughts?

[Andrew Cagney]

> It is wrong.  "pass" must be "passes" to match the singular "user".
> 
> I'll fix this.  Thanks. 

FYI, I checked this in with the above tweek.

Andrew