On Thu, Aug 06, 2015 at 12:35:30PM +0800, Wangnan (F) wrote: > > > On 2015/8/6 11:22, Alexei Starovoitov wrote: > >On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote: > >>It doesn't work for me at first since in my llvm there's only > >>llvm.bpf.load.*. > >> > >>I think llvm.bpf.store.* belone to some patches you haven't posted yet? > >nope. only loads have special instructions ld_abs/ld_ind > >which are represented by these intrinsics. > >stores, so far, are done via single bpf_store_bytes() helper function. > > > >>>the typeid changing ids with order is surprising. > >>>I think the assertion in ExtractTypeInfo() is not hard. > >>>Just there were no such use cases. May be we can do something > >>>similar to what LowerIntrinsicCall() does and lower it differently > >>>in the backend. > >>> > >>But in backend can we still get type information? I thought type is > >>meaningful in frontend only, and backend behaviors is unable to affect > >>DWARF generation, right? > >why do we need to affect type generation? we just need to know dwarf > >type id in the backend, so we can emit it as a constant. > >I still think lowering eh_typeid_for differently may work. > >Like instead of doing > >GV = ExtractTypeInfo(I.getArgOperand(0)) followed by > >getMachineFunction().getMMI().getTypeIDFor(GV) > >we can get dwarf type id from I.getArgOperand(0) if it's > >any pointer to struct type. > > I have a bad news to tell: > > #include <stdio.h> > struct my_str { > int x; > int y; > } __gv_my_str; > struct my_str __gv_my_str_; > > struct my_str2 { > int x; > int y; > } __gv_my_str2; > > int typeid(void *p) asm("llvm.eh.typeid.for"); > > int main() > { > printf("%d\n", typeid(&__gv_my_str)); > printf("%d\n", typeid(&__gv_my_str_)); > printf("%d\n", typeid(&__gv_my_str2)); > return 0; > } > > Compiled with clang into x86 executable, then: > > $ ./a.out > 3 > 2 > 1 > > See? I have two types but reported 3 IDs.
that's expected. We don't have to use default lowering of typeid_for with getTypeIDFor. bpf backend specific lowering can be different, though in this case it's odd that id for __gv_my_str and __gv_my_str_ are different. __gv_my_str and __gv_my_str2 should be different. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/