All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@fb.com>
To: David Miller <davem@davemloft.net>
Cc: <daniel@iogearbox.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next] selftests/bpf: get rid of -D__x86_64__
Date: Wed, 3 May 2017 20:30:22 -0700	[thread overview]
Message-ID: <d809baa4-c864-af99-38af-fbcb6637ca2b@fb.com> (raw)
In-Reply-To: <20170503.133512.310640909764585408.davem@davemloft.net>

On 5/3/17 10:35 AM, David Miller wrote:
> From: Alexei Starovoitov <ast@fb.com>
> Date: Wed, 3 May 2017 09:54:42 -0700
>
>> /usr/include/asm/types.h -> asm-generic/int-ll64.h
>> as far as I can see that should be the same on most archs.
>> Why doesn't it work for sparc?
>
> You can't assume anything about the kernel headers installed,
> on my debian Sparc box /usr/include/asm/types.h is below.
>
> They do things this way to facilitate multiarch building.  I think
> it's pretty reasonable.
>
> #ifndef _SPARC_TYPES_H
> #define _SPARC_TYPES_H
> /*
>  * This file is never included by application software unless
>  * explicitly requested (e.g., via linux/types.h) in which case the
>  * application is Linux specific so (user-) name space pollution is
>  * not a major issue.  However, for interoperability, libraries still
>  * need to be careful to avoid a name clashes.
>  */
>
> #if defined(__sparc__)
>
> #include <asm-generic/int-ll64.h>
>
> #ifndef __ASSEMBLY__
>
> typedef unsigned short umode_t;
>
> #endif /* __ASSEMBLY__ */
>
> #endif /* defined(__sparc__) */

if it was something like
#ifdef __sparc__
...
#else
#include_next <asm/types.h>

I would buy that debian folks indeed care about multi-arch, but
what above does is making #include <linux/types.h> to be a nop
for any cross-compiler on sparc that included it.
Which is probably quite painful to debug as we found out.
You're right that we cannot assume much about /usr/include craziness.
In that sense adding __native_arch__ macro is also wrong, since
it assumes sane /usr/include without inline asm or other things
that clang for bpf arch can consume.
In that sense the only way to be independent from arch dependent
things in /usr/include is to put all arch specific headers
into our own dir in tools/selftests/ (or may be tools/bpf/include)
and point clang to that. I think the list of .h in there will be
limited. Only things like linux/types.h and gnu/stubs.h,
so it will be manageable.
Thoughts?

  reply	other threads:[~2017-05-04  3:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03  4:14 [PATCH net-next] selftests/bpf: get rid of -D__x86_64__ Alexei Starovoitov
2017-05-03 13:52 ` David Miller
2017-05-03 16:06   ` David Miller
2017-05-03 16:54     ` Alexei Starovoitov
2017-05-03 17:35       ` David Miller
2017-05-04  3:30         ` Alexei Starovoitov [this message]
2017-05-04 13:37           ` David Miller
2017-05-04 23:34             ` Alexei Starovoitov
2017-05-11 19:02               ` David Miller
2017-05-11 22:58                 ` Alexei Starovoitov
2017-05-12  1:29                   ` David Miller
2017-05-12  5:07                     ` Alexei Starovoitov
2017-05-12 14:46                       ` David Miller
2017-05-12 15:17                         ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d809baa4-c864-af99-38af-fbcb6637ca2b@fb.com \
    --to=ast@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.