Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1503984

Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts

Show all headers | View raw

On Wed, 19 Oct 2016, Peter Zijlstra wrote:

> On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote:
> > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> 
> > > This is also an entirely different class of optimizations than the whole
> > > pointer arithmetic is only valid inside an object thing.
> > 
> > Yes, it is not related to that.  I've opened 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 to track an
> > inconsistency in that new optimization.
> > 
> > > The kernel very much relies on unbounded pointer arithmetic, including
> > > overflow. Sure, C language says its UB, but we know our memory layout,
> > > and it would be very helpful if we could define it.
> > 
> > It's well-defined and correctly handled if you do the arithmetic
> > in uintptr_t.  No need for knobs.
> 
> So why not extend that to the pointers themselves and be done with it?
> 
> In any case, so you're saying our:
> 
> #define RELOC_HIDE(ptr, off)						\
> ({									\
> 	unsigned long __ptr;						\
> 	__asm__ ("" : "=r"(__ptr) : "0"(ptr));				\
> 	(typeof(ptr)) (__ptr + (off));					\
> })
> 
> could be written like:
> 
> #define RELOC_HIDE(ptr, off)			\
> ({						\
> 	uintptr_t __ptr = (ptr);		\
> 	(typeof(ptr)) (__ptr + (off));		\
> })
> 
> Without laundering it through inline asm?

I think so.

> Is there any advantage to doing so?

asms always introduce issues with optimization passes that do not
bother to handle it (and give up).  And then there is register
allocation - not sure how it is affected by the asm.

Generally I'd say if you can do it w/o asm then better..

Note that old GCC may have had bugs that made the uintptr_t variant
w/o the asm not work.

> But this still means we need to be aware of this and use these macros to
> launder our pointers.

Yes, if you base 'ptr' on the address of a declaration at least.
 
> Which gets us back to the issue that started this whole thread. We have
> code that now gets miscompiled, silently.
> 
> That is a bad situation. So we need to either avoid the miscompilation,
> or make it verbose.

GCC 7 is still not released and I think we should try not to break
things without a good reason.

> > > Can't we get a knob extending -fno-strict-aliasing to define pointer
> > > arithmetic outside of objects and overflow? I mean, we already use that,
> > > we also use -fno-strict-overflow and a whole bunch of others.
> > > 
> > > At the very least, it would be nice to get a -W flag for when this alias
> > > analysis stuff kills something so we can at least know when GCC goes and
> > > defeats us.
> > 
> > What kind of warning do you envision?
> > 
> > "warning: optimized address comparison to always true/false"
> > 
> > ?  That would trigger all over the place.
> 
> That is indeed what I was thinking of. And I have no idea how often that
> would trigger on the kernel.
> 
> I'm thinking that if this WARN isn't subject to false
> positives we could live with that. Its the false positives that render
> other warnings useless (too much noise on perfectly fine code etc..).
> 
> /me ponders..
> 
> So there might be a problem if this triggers in generic code due to
> conditions at its use site. There we would not want to, nor could, fix
> the generic code because in generic the thing would not be optimized. So
> maybe we'd need an annotation still.

For C++ these kind of warnings trigger whenever abstraction penalty
is removed.  Like the typical

 template <int i> foo () { if (i) { <code> } }

triggering for a hypothetical -Wdead-code for i == 0.  The kernel
is known for its "C" abstraction stuff and I can believe that
such -W flag would trigger for cases where abstraction is removed.

Richard.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 00/12] external array access helpers Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 17:30 +0200
  [PATCH 07/12] tracing: declare __{start,stop}_ftrace_enum_maps as external array Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 17:30 +0200
  [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 17:30 +0200
    Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-17 09:10 +0200
    Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Peter Zijlstra <peterz@infradead.org> - 2016-10-17 10:40 +0200
      Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Jiri Slaby <jslaby@suse.cz> - 2016-10-17 11:10 +0200
        Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Peter Zijlstra <peterz@infradead.org> - 2016-10-17 11:10 +0200
          Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-17 13:30 +0200
            Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Peter Zijlstra <peterz@infradead.org> - 2016-10-17 13:50 +0200
              Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-18 10:10 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-10-18 23:20 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Richard Biener <rguenther@suse.de> - 2016-10-19 16:30 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Peter Zijlstra <peterz@infradead.org> - 2016-10-19 16:40 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Richard Biener <rguenther@suse.de> - 2016-10-19 18:00 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Peter Zijlstra <peterz@infradead.org> - 2016-10-19 18:10 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Richard Biener <rguenther@suse.de> - 2016-10-19 17:10 +0200
                Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Peter Zijlstra <peterz@infradead.org> - 2016-10-19 18:20 +0200
              Re: [PATCH 01/12] extarray: define helpers for arrays defined in  linker scripts Jiri Slaby <jslaby@suse.cz> - 2016-10-19 16:50 +0200
  [PATCH 12/12] dynamic debug: declare table as external array Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 17:30 +0200
  [PATCH 10/12] serial_core: declare __earlycon_table{,_end} as external array Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 18:00 +0200
  [PATCH 08/12] tracing: declare __trace_bprintk_fmt/__tracepoint_str as external arrays Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 18:00 +0200
  [PATCH 09/12] tracing: declare __{start,stop}_syscalls_metadata as external array Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 18:20 +0200
  Re: [PATCH 00/12] external array access helpers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-16 18:20 +0200
    Re: [PATCH 00/12] external array access helpers Vegard Nossum <vegard.nossum@oracle.com> - 2016-10-16 19:30 +0200
      Re: [PATCH 00/12] external array access helpers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-10-17 09:10 +0200
    Re: [PATCH 00/12] external array access helpers Jiri Slaby <jslaby@suse.cz> - 2016-10-17 08:30 +0200

csiph-web