Re: [PATCH] sim: add --map-info option

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 14 December 2010 19:03:02, Mike Frysinger wrote:
> On Tuesday, December 14, 2010 13:50:27 Pedro Alves wrote:
> > On Tuesday 14 December 2010 18:33:09, Mike Frysinger wrote:
> > > ok, some of the (long) casts are necessary.  specifically, the ones who
> > > have a type of "unsigned_word" as those depend on the target bitness
> > > (which could be 16, 32, or 64).
> > 
> > long is 32-bit on Win64.
> 
> so what you're saying is that all the sim code that casts unsigned_word to a 
> long is broken and not just the code in my patch.  sounds like a bigger 
> problem that should be fixed independently and by someone who is interested in 
> testing on systems dumb enough to do LLP64.

No, I just said "long is 32-bit on Win64".

I just noticed src/README-HACKING:

C Language Assumptions
======================

The programmer may assume that the simulator is being built using an
ANSI C compiler that supports a 64 bit data type.  Consequently:

	o	prototypes can be used (although using
		PARAMS() and K&R declarations wouldn't
		go astray).

	o	If sim-types.h is included, the two
		types signed64 and unsigned64 are
		available.

	o	The type `unsigned' is valid.

However, the user should be aware of the following:

	o	GCC's `<number>LL' is NOT acceptable.
		Microsoft-C doesn't reconize it.

	o	MSC's `<number>i64' is NOT acceptable.
		GCC doesn't reconize it.

	o	GCC's `long long' MSC's `_int64' can
		NOT be used to define 64 bit integer data
		types.

	o	An empty array (eg int a[0]) is not valid.


but if the sim is already not following its own rules, let's leave it.
For GDB code proper, long would be unacceptible.

-- 
Pedro Alves