Unnecessary Relocation Hiding?

Unnecessary Relocation Hiding?

[Dong Feng]

Hi, all,

I have a question. Why shall we need a RELOC_HIDE() macro in the
definition of per_cpu()? Maybe the question is actually why we need
macro RELOC_HIDE() at all. I changed the following line in
include/asm-generic/percpu.h, from

#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))

to

#define per_cpu(var, cpu) (*((unsigned long)(&per_cpu__##var) +
__per_cpu_offset[cpu]))

I recompiled the code and it works well on my Intel Dual-core laptop.
It essentially the same as to change the definition of RELOC_HIDE(),
from

#define RELOC_HIDE(ptr, off) \
  ({ unsigned long __ptr; \
    __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
    (typeof(ptr)) (__ptr + (off)); })

to


#define RELOC_HIDE(ptr, off) \
  ({ unsigned long __ptr; \
    __ptr = (unsigned long)ptr; \
    (typeof(ptr)) (__ptr + (off)); })


Why shouldn't we have a pure C solution in this part?

Best Regards.
Feng,Dong

Unnecessary Relocation Hiding?

[Dong Feng]

Hi, all,

I have a question. Why shall we need a RELOC_HIDE() macro in the
definition of per_cpu()? Maybe the question is actually why we need
macro RELOC_HIDE() at all. I changed the following line in
include/asm-generic/percpu.h, from

#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))

to

#define per_cpu(var, cpu) (*((unsigned long)(&per_cpu__##var) +
__per_cpu_offset[cpu]))

I recompiled the code and it works well on my Intel Dual-core laptop.
It essentially the same as to change the definition of RELOC_HIDE(),
from

#define RELOC_HIDE(ptr, off) \
 ({ unsigned long __ptr; \
   __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
   (typeof(ptr)) (__ptr + (off)); })

to


#define RELOC_HIDE(ptr, off) \
 ({ unsigned long __ptr; \
   __ptr = (unsigned long)ptr; \
   (typeof(ptr)) (__ptr + (off)); })


Why shouldn't we have a pure C solution in this part?

Best Regards.
Feng,Dong

Re: Unnecessary Relocation Hiding?

[Christoph Lameter]

On Wed, 23 Aug 2006, Dong Feng wrote:

> I have a question. Why shall we need a RELOC_HIDE() macro in the
> definition of per_cpu()? Maybe the question is actually why we need
> macro RELOC_HIDE() at all. I changed the following line in
> include/asm-generic/percpu.h, from

Guess it was copied from IA64 but the semantics were not preserved.
I think it should either be changed the way you suggest or the 
implementation needs to be fixed to actually do a linker relocation.

Re: Unnecessary Relocation Hiding?

[Andi Kleen]

On Thursday 24 August 2006 20:26, Christoph Lameter wrote:
> On Wed, 23 Aug 2006, Dong Feng wrote:
> 
> > I have a question. Why shall we need a RELOC_HIDE() macro in the
> > definition of per_cpu()? Maybe the question is actually why we need
> > macro RELOC_HIDE() at all. I changed the following line in
> > include/asm-generic/percpu.h, from
> 
> Guess it was copied from IA64 but the semantics were not preserved.
> I think it should either be changed the way you suggest or the 
> implementation needs to be fixed to actually do a linker relocation.

The reason the original code is like it is because gcc assumes there
is no wrapping on arithmetic on symbol addresses (it is allowed to assume
that because it is undefined in the C standard). And in same cases wrapping
can happen. There was at least one miscompilation in the past that lead to the 
current construct.

-Andi

Re: Unnecessary Relocation Hiding?

[Paul Mackerras]

Christoph Lameter writes:

> On Wed, 23 Aug 2006, Dong Feng wrote:
> 
> > I have a question. Why shall we need a RELOC_HIDE() macro in the
> > definition of per_cpu()? Maybe the question is actually why we need
> > macro RELOC_HIDE() at all. I changed the following line in
> > include/asm-generic/percpu.h, from
> 
> Guess it was copied from IA64 but the semantics were not preserved.
> I think it should either be changed the way you suggest or the 
> implementation needs to be fixed to actually do a linker relocation.

No, RELOC_HIDE came from ppc originally.  The reason for it is that
gcc assumes that if you add something on to the address of a symbol,
the resulting address is still inside the bounds of the symbol, and do
optimizations based on that.  The RELOC_HIDE macro is designed to
prevent gcc knowing that the resulting pointer is obtained by adding
an offset to the address of a symbol.  As far as gcc knows, the
resulting pointer could point to anything.

It has nothing to do with linker relocations.

Paul.

Re: Unnecessary Relocation Hiding?

[Dong Feng]

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?

After all, we are writing an OS in C not in pure assembly, so I am
just trying to learn some generial rules to mimize the raw assembly in
development.

Feng,Dong


2006/8/25, Paul Mackerras <paulus@samba.org>:
> Christoph Lameter writes:
>
> No, RELOC_HIDE came from ppc originally.  The reason for it is that
> gcc assumes that if you add something on to the address of a symbol,
> the resulting address is still inside the bounds of the symbol, and do
> optimizations based on that.  The RELOC_HIDE macro is designed to
> prevent gcc knowing that the resulting pointer is obtained by adding
> an offset to the address of a symbol.  As far as gcc knows, the
> resulting pointer could point to anything.
>
> It has nothing to do with linker relocations.
>
> Paul.

Re: Unnecessary Relocation Hiding?

[Paul Mackerras]

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.

Re: Unnecessary Relocation Hiding?

[Andi Kleen]

On Friday 25 August 2006 03:30, Dong Feng wrote:
> 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?
> 
> After all, we are writing an OS in C not in pure assembly, so I am
> just trying to learn some generial rules to mimize the raw assembly in
> development.

In theory anything that is undefined in the C standard should be avoided
because gcc is free to make assumptions about it and generate unexpected 
code.

In practice Linux does a lot of not-quite-legal-in-portable-C things
already, but tries to avoid areas that are known to have miscompiled in
the past.

Best is to avoid undefined behaviour in new code.

-Andi

Fwd: Unnecessary Relocation Hiding?

[Dong Feng]

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 <paulus@samba.org>:
> 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.
>

Re: Unnecessary Relocation Hiding?

[Paul Mackerras]

Andi Kleen writes:

> Best is to avoid undefined behaviour in new code.

Of course.  But do you have a way to implement per_cpu() without it?

Paul.

Re: Unnecessary Relocation Hiding?

[Andi Kleen]

On Friday 25 August 2006 09:20, Paul Mackerras wrote:
> Andi Kleen writes:
> 
> > Best is to avoid undefined behaviour in new code.
> 
> Of course.  But do you have a way to implement per_cpu() without it?

I was describing the ideal, not the practical reality.

-Andi