On Thu, 14 Feb 2019 at 21:39, Y Song <ys114...@gmail.com> wrote: > > On Mon, Feb 11, 2019 at 4:48 PM Joe Stringer <j...@wand.net.nz> wrote: > > > > Support loads of static 32-bit data when BPF writers make use of > > convenience macros for accessing static global data variables. A later > > patch in this series will demonstrate its usage in a selftest. > > > > As of LLVM-7, this technique only works with 32-bit data, as LLVM will > > complain if this technique is attempted with data of other sizes: > > > > LLVM ERROR: Unsupported relocation: try to compile with -O2 or above, > > or check your static variable usage > > A little bit clarification from compiler side. > The above compiler error is to prevent people use static variables since > current > kernel/libbpf does not handle this. The compiler only warns if .bss or > .data section > has more than one definitions. The first definition always has section offset > 0 > and the compiler did not warn.
Ah, interesting. I observed that warning when I attempted to define global variables of multiple sizes, and I thought also with sizes other than 32-bit. This clarifies things a bit, thanks. For the .bss my observation was that if you had a definition like: static int a = 0; Then this will be placed into .bss, hence why I looked into the approach from this patch for patch 3 as well. > The restriction is a little strange. To only work with 32-bit data is > not a right > statement. The following are some examples. > > The following static variable definitions will succeed: > static int a; /* one in .bss */ > static long b = 2; /* one in .data */ > > The following definitions will fail as both in .bss. > static int a; > static int b; > > The following definitions will fail as both in .data: > static char a = 2; > static int b = 3; Are there type restrictions or something? I've been defining multiple static uint32_t and using them per the approach in this patch series without hitting this compiler assertion. > Using global variables can prevent compiler errors. > maps are defined as globals and the compiler does not > check whether a particular global variable is defining a map or not. > > If you just use static variable like below > static int a = 2; > without potential assignment to a, the compiler will replace variable > a with 2 at compile time. > An alternative is to define like below > static volatile int a = 2; > You can get a "load" for variable "a" in the bpf load even if there is > no assignment to a. I'll take a closer look at this too. > Maybe now is the time to remove the compiler assertions as > libbpf/kernel starts to > handle static variables? I don't understand why those assertions exists in this form. It already allows code which will not load with libbpf (ie generate any .data/.bss), does it help prevent unexpected situations for developers?
