[obish] More osabi comments

[obish] More osabi comments

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

More comments the better ...

Recent discussions to do with rs6000 compatibility left me wondering how 
come "amd64 can run code for i386" wasn't getting a hit.   The attached 
comment explains why the test (both old and new) works for the 32-bit vs 
64-bit case.

I also changed "atom" to the more common OO term "singleton".

committed,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1864 bytes --]

2003-10-24  Andrew Cagney  <cagney@redhat.com>

	* osabi.c (gdbarch_init_osabi): Add comment on 32-bit vs 64-bit.
	(can_run_code_for): Use the OO term "singleton".

Index: osabi.c
===================================================================
RCS file: /cvs/src/src/gdb/osabi.c,v
retrieving revision 1.18
diff -u -r1.18 osabi.c
--- osabi.c	23 Oct 2003 21:15:50 -0000	1.18
+++ osabi.c	24 Oct 2003 15:35:26 -0000
@@ -295,9 +295,9 @@
      written for B, but B can't run code written for A, then it'll
      return A.
 
-     struct bfd_arch_info objects are atoms: that is, there's supposed
-     to be exactly one instance for a given machine.  So you can tell
-     whether two are equivalent by comparing pointers.  */
+     struct bfd_arch_info objects are singletons: that is, there's
+     supposed to be exactly one instance for a given machine.  So you
+     can tell whether two are equivalent by comparing pointers.  */
   return (a == b || a->compatible (a, b) == a);
 }
 
@@ -333,6 +333,14 @@
 	 type that is compatible with the desired machine type.  Right
 	 now we simply return the first match, which is fine for now.
 	 However, we might want to do something smarter in the future.  */
+      /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
+         is implemented using BFD's compatible method (a->compatible
+         (b) == a -- the lowest common denominator between a and b is
+         a).  That method's definition of compatible may not be as you
+         expect.  For instance, while "amd64 can run code for i386"
+         (or more generally "64-bit ISA can run code for the 32-bit
+         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and
+         64-bit "compatible" so won't get a match.  */
       if (can_run_code_for (arch_info, handler->arch_info))
 	{
 	  (*handler->init_osabi) (info, gdbarch);

Re: [obish] More osabi comments

[Kevin Buettner]

On Oct 24, 11:43am, Andrew Cagney wrote:

> +         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and

s/Fortunatly/Fortunately/

Re: [obish] More osabi comments

[Daniel Jacobowitz]

On Fri, Oct 24, 2003 at 11:43:54AM -0400, Andrew Cagney wrote:
> More comments the better ...
> 
> Recent discussions to do with rs6000 compatibility left me wondering how 
> come "amd64 can run code for i386" wasn't getting a hit.   The attached 
> comment explains why the test (both old and new) works for the 32-bit vs 
> 64-bit case.
> 
> I also changed "atom" to the more common OO term "singleton".
> 
> committed,
> Andrew

> @@ -333,6 +333,14 @@
>  	 type that is compatible with the desired machine type.  Right
>  	 now we simply return the first match, which is fine for now.
>  	 However, we might want to do something smarter in the future.  */
> +      /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
> +         is implemented using BFD's compatible method (a->compatible
> +         (b) == a -- the lowest common denominator between a and b is
> +         a).  That method's definition of compatible may not be as you
> +         expect.  For instance, while "amd64 can run code for i386"

Did you mean to have another clause, or is this "while" left over?

> +         (or more generally "64-bit ISA can run code for the 32-bit
> +         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and

"Fortunately"

> +         64-bit "compatible" so won't get a match.  */

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [obish] More osabi comments

[Andrew Cagney]

> 
> Did you mean to have another clause, or is this "while" left over?

Hmm, yes.

>> +         (or more generally "64-bit ISA can run code for the 32-bit
>> +         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and
> 
> 
> "Fortunately"

Which is wierd, I did spell check it, I guess just not the final version.

Andrew

Re: [obish] More osabi comments

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
> More comments the better ...
> 
> Recent discussions to do with rs6000 compatibility left me wondering
> how come "amd64 can run code for i386" wasn't getting a hit.   The
> attached comment explains why the test (both old and new) works for
> the 32-bit vs 64-bit case.
> 
> I also changed "atom" to the more common OO term "singleton".

For what it's worth, I got "atom" from bfd/archures.c:

    SECTION
            Architectures

            BFD keeps one atom in a BFD describing the
            architecture of the data attached to the BFD: a pointer to a
            <<bfd_arch_info_type>>.

There's something to be said for using the same terminology used in
the code that defines the data structures one is discussing.  Perhaps
a corresponding patch for BFD would be good, too.

> +      /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
> +         is implemented using BFD's compatible method (a->compatible
> +         (b) == a -- the lowest common denominator between a and b is
> +         a).  That method's definition of compatible may not be as you
> +         expect.  For instance, while "amd64 can run code for i386"
> +         (or more generally "64-bit ISA can run code for the 32-bit
> +         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and
> +         64-bit "compatible" so won't get a match.  */

(Incomplete sentence in there.)

This comment implies that can_run_code_for (A, B) might return zero
when A actually can run code for B.  That's not so.

The example you give is, I think, incorrect.  The x86_64 64-bit ISA is
not a superset with the IA-32 ISA: the 64-bit ISA takes over the
one-byte opcodes for INC and DEC, 0x40 -- 0x4f, for use as its new REX
prefix codes.  So one can't include i386 code in an x86-64 64-bit mode
code segment.  One must mark the code segment as being in
'compatibility mode' to execute IA-32 code.  For details, see:

http://www.amd.com/products/cpg/64bit/pdf/x86-64_overview.pdf

So, can_run_code_for (&bfd_x86_64_arch, &bfd_i386_arch) == 0, just as
it should.

Re: [obish] More osabi comments

[Andrew Cagney]

>> +      /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
>> +         is implemented using BFD's compatible method (a->compatible
>> +         (b) == a -- the lowest common denominator between a and b is
>> +         a).  That method's definition of compatible may not be as you
>> +         expect.  For instance, while "amd64 can run code for i386"
>> +         (or more generally "64-bit ISA can run code for the 32-bit
>> +         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and
>> +         64-bit "compatible" so won't get a match.  */
> 
> 
> (Incomplete sentence in there.)

You missed the "fortunately".

> This comment implies that can_run_code_for (A, B) might return zero
> when A actually can run code for B.

That's both correct and the intent: "amd64 can run code for i386", 
"ppc64 can run code or ppc", "sh64 can run code for sh", "mips64 can run 
code for mips", and "ia64 can run code for ia32".  They all fortunately 
return zero.

Andrew

Re: [obish] More osabi comments

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:

> >> +      /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
> >> +         is implemented using BFD's compatible method (a->compatible
> >> +         (b) == a -- the lowest common denominator between a and b is
> >> +         a).  That method's definition of compatible may not be as you
> >> +         expect.  For instance, while "amd64 can run code for i386"
> >> +         (or more generally "64-bit ISA can run code for the 32-bit
> >> +         ISA").  Fortunatly, BFD doesn't normally consider 32-bit and
> >> +         64-bit "compatible" so won't get a match.  */
> > (Incomplete sentence in there.)
> 
> You missed the "fortunately".
> 
> > This comment implies that can_run_code_for (A, B) might return zero
> > when A actually can run code for B.
> 
> That's both correct and the intent: "amd64 can run code for i386",
> "ppc64 can run code or ppc", "sh64 can run code for sh", "mips64 can
> run code for mips", and "ia64 can run code for ia32".  They all
> fortunately return zero.

The bfd_mach_foo things refer to ISAs, not chips.  So the
'can_run_code_for' is talking about whether one ISA is an
upwards-compatible extension of another, not a question of which ISAs
a chip may implement.  Is the ISA / chip distinction the one the
comment is trying to make?

Re: [obish] More osabi comments

[Andrew Cagney]

> The bfd_mach_foo things refer to ISAs, not chips.  So the
> 'can_run_code_for' is talking about whether one ISA is an
> upwards-compatible extension of another, not a question of which ISAs
> a chip may implement.  Is the ISA / chip distinction the one the
> comment is trying to make?

This is how it now reads:

       /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
          is implemented using BFD's compatible method (a->compatible
          (b) == a -- the lowest common denominator between a and b is
          a).  That method's definition of compatible may not be as you
          expect.  For instance the test "amd64 can run code for i386"
          (or more generally "64-bit ISA can run code for the 32-bit
          ISA").  BFD doesn't normally consider 32-bit and 64-bit
          "compatible" so it doesn't succeed.  */

enjoy,
Andrew