hctim added inline comments.
================ Comment at: llvm/lib/DebugInfo/DWARF/DWARFUnit.cpp:769-783 + DataExtractor Data(Location.Expr, /*IsLittleEndian=*/true, 8); + uint64_t DataOffset = 0; + uint8_t Operation = Data.getU8(&DataOffset); + if (Operation == dwarf::DW_OP_addr) { + uint64_t Pointer = Data.getAddress(&DataOffset); + VariableDieMap[Pointer] = Die; + return; ---------------- dblaikie wrote: > Are there any examples of global merge where this might not be correct? > > Like if a global was described as "addrx, 5, add" (eg: 5 beyond this address) > then only looking at the first operation might mis-conclude that the variable > is at this address when it's at 5 bytes past this address - and some other > variable is at this address) > > LLVM has a "global merge" optimization that might cause something like this. > Let's see if I can create an example. > > Ah, yeah, here we go: > ``` > static int x; > static int y; > int *f(bool b) { return b ? &x : &y; } > ``` > ``` > $ clang++-tot -O3 merge.cpp -c -g -target aarch64-linux-gnuabi -mllvm > -global-merge-ignore-single-use && llvm-dwarfdump-tot merge.o | grep > DW_AT_location > DW_AT_location (DW_OP_addrx 0x0) > DW_AT_location (DW_OP_addrx 0x0, DW_OP_plus_uconst 0x4) > ``` > > (the `-global-merge-ignore-single-use` is to simplify the test case - without > that it could still be tickled with a more complicated example - seems we > only enable global merge on ARM 32 and 64 bit due to the higher register > pressure there, by the sounds of it) > > I'm guessing this patch would overwrite the VariableDieMap entry for the > first global with the second one so queries for the first address would > result in the second DIE and queries for the second address wouldn't give any > result? > > Hmm, also - how does this handle queries that aren't at exactly the starting > address of the variable? Presumably the `DW_AT_type` of the > `DW_TAG_global_variable` would have to be inspected to find the size of the > variable starting at the address, and any query in that range should be > successful? I've added some handling for the `DW_OP_plus_uconst`. Unfortunately I didn't find any generic existing handling for the expression evaluation (which surprised me, maybe I just suck at looking), so I'm just making the assumption that global variable addresses aren't described using `DW_OP_plus` or anything else... Fixed it up to now provide line info when you provide an address halfway through a symbol. Good thing there wasn't a big impact in D123534 about keeping the string sizes around :). Worst case (if the type info sucks) we just only accept the precise start addresses of the symbols. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123538/new/ https://reviews.llvm.org/D123538 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits