Messages in this thread | | | Date | Thu, 6 Aug 2015 12:35:30 +0800 | From | "Wangnan (F)" <> | Subject | Re: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event |
| |
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.
And here is the implementation of getTypeIDFor, in lib/CodeGen/MachineModuleInfo.cpp:
unsigned MachineModuleInfo::getTypeIDFor(const GlobalValue *TI) { for (unsigned i = 0, N = TypeInfos.size(); i != N; ++i) if (TypeInfos[i] == TI) return i + 1;
TypeInfos.push_back(TI); return TypeInfos.size(); }
It only checks value in a stupid way.
Now the dwarf side becomes clear (see my other response), but the frontend may require totally reconsidering.
Do you know someone in LLVM-dev who can help us?
Thank you.
> I'm not familiar with dwarf handling part of llvm, but feels possible. >
| |