Pavel Labath

> I wonder if these U entries could be the problem: They might be. It would be worth checking what does the ``` addr_t jit_addr = GetSymbolAddress( module_list, ConstString("__jit_debug_register_code"), eSymbolTypeAny);...

I'd actually say that simplified template names are the best way to fix this problem. It completely sidesteps the demangled name consistency problem -- by not including the demangled name...

> (minor aside: Looks like something in the mail/github issues pipeline might'vee lost some stuff - I guess this was meant to read: It seems the same thing happened to...

The test does look like it could be easily broken or invalidated by a change in how the compiler emits debug info. There probably is a better way to test...

> It is the combination of the first and third. For completeness. > > we do an step-over, which lands us at an instruction, which happens to be the first...

Yeah, that sounds like a bug. A different one that what you are fixing, but I think it's kind of related, as now the stepping machinery who concludes it has...

Cool. The test case looks good. Someone might want to look at the DAP part.

The way I understand this, this patch isn't trying to fix the step over problem (https://github.com/llvm/llvm-project/issues/144061). What it does is fix a different (but similar) problem in lldb-dap where it...

> Clang only supports DWARF64 for ELF: I'm surprised that is the case, but I don't think it matters because I think you should be able to test all of...

Also note that there are remnants of our previous attempt at dwarf64 support (which was deleted many years ago) lying around the DWARFDataExtractor class. However, since this isn't how *llvm*'s...