The mail was rejected by the list because I sent it in HTML format, my
fault. Resend it in plain-text and you can delete the version you do
not like.
I put my understanding below for your confirm or correcting, ...
Once I get a C pointer, say "some_type_t * ptr;" ...
1. If I want to treat it as an ordinary C array and retrieve elements
from it, then plain pointer addition is OK. Like this:
some_type_t * ptr1 = ptr + 2;
2. If I want to add some offset to it (that is, the ptr need to be
converted to _void *_ or _unsigned long_ before manipulated), and the
offset does not exceed sizeof(some_type_t), then plain C addtion is
OK. Like this:
unsigned long raw_addr = (unsigned long)ptr;
int *second_mem = raw_addr + sizeof(int); // as long as the
sizeof(int) less than
// the
sizeof(some_type_t), for example,
//
some_type_t really has two members and the
// the
first is really an integer.
3. If I want to add some offset to it (after converted to _void *_ or
_unsigned long_). However, the offset exceed sizeof(some_type_t). In
this case, gcc still (mis-)assume that I would want to do the same
thing as case 2 (but I am not actually). In this case, I have to use
RELOC_HIDE. And this is exactly what per_cpu() going to do.
== the end of the description of my understanding ==
Thanks.
Feng,Dong
2006/8/25, Paul Mackerras <[email protected]>:
Dong Feng writes:
> Sorry for perhaps extending the specific question to a more generic
> one. In which cases shall we, in current or future development,
> prevent gcc from knowing a pointer-addition in the way RELOC_HIDE? And
> in what cases shall we just write pure C point addition?
Where you are saying to gcc "you think this variable is at this
address, but I know it's actually at this other address over here" you
should use RELOC_HIDE. Where the addition is being used to get the
address of some part of the object (so the resulting address is still
within the object) you can just use plain addition.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
