RE: Defining address's offset.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

	I defined UNITS_PER_WORD as 1, but that alone did not change a thing as far
as I could see.
When I tried to define BITS_PER_UNIT as 32 it thown me out with Segmentation
fault and I can't
track the reason for it.

	My porting is based on arc's and in arc it has the same effect
(Segmentation fault when BITS_PER_UNIT
defined as 32), so you can see the exact situation there.

	The example I checked on is same as yours:
		     int *p;
		     void foo() { p++; }.

Any help will be appreciated.
     Liza


-----Original Message-----
From: Ian Lance Taylor [mailto:ian@xxxxxxxx]
Sent: Thursday, February 03, 2005 7:07 PM
To: Liza Atkin
Subject: Re: Defining address's offset.


"Liza Atkin" <latkin@xxxxxxxxxxxx> writes:

Please reply to the list, not just to me.  Thanks.

> Now here is the explanation of a particular case:
>
> load R2 0x8000000000
> load R2 0x8000000001
>
> Now, this is true that our machine uses 32-bit words, but when moving to
> next word
> we want to increase the address index by 1 only and not by 4 bytes.
>
> Or in your example:
> "
>     int *p;
>     void foo() { p++; }
>
> Then p might have the value, e.g., 0x100 before calling foo, and x0104
> after. "
> What I want is  to get a value of 0x101 after.

In that case, you need to look at the definitions of BITS_PER_UNIT and
UNITS_PER_WORD.

The c4x port in the main sources does this kind of thing.  Look at
gcc/config/c4x/c4x.h.

Ian


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux