From: Alexei Starovoitov
Date: Sat, 29 Apr 2017 23:35:30 -0700
> On 4/29/17 11:38 AM, David Miller wrote:
>> or, taking it one step further, do the following since we know this
>> maps to a 32-bit FD:
>>
>> mov32 r1, %map(hash_map)
>
> hence this approach won't work without serious elf lo
On 4/29/17 11:38 AM, David Miller wrote:
or whatever. And then for assembler syntax, use something like:
%map(SYMBOL)
So you would go:
ldimm64 r1, %map(hash_map)
sure. that works.
The elf loaders should have checked relo code, of course.
I guess the above ldimm64 should prob
From: Alexei Starovoitov
Date: Thu, 27 Apr 2017 19:06:14 -0700
> So in asm the map lookup will look like:
> .sectionmaps,"aw",@progbits
> .globl hashmap_def
> hashmap_def:
> .long 1 # type
> .long 24 # key_size
> .long 40 # value_size
>
On 4/27/17 1:42 PM, David Miller wrote:
Can you guys give me some kind of idea of how it might be nice to
represent calls and tailcalls in assembler files?
llvm prints them as 'call 1' for bpf_map_lookup
and 'call 12' for bpf_tail_call.
In the instruction stream bpf_tail_call is no different
t
Can you guys give me some kind of idea of how it might be nice to
represent calls and tailcalls in assembler files?
And also the emission of maps.
Right now I just have the assembler looking for 32-bit immediate
values for call and tailcall instructions.
Looking at samples/bpf/sockex3_kern.c we
