This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [obish] More osabi comments


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]