search for: dw_op_entry_values

...arameter’s entry value as a real value in the current frame. It relies on the call-site info provided, and the more DW_AT_call_value generated, the more debug location inputs using DW_OP_entry_value will be turned into real values. Current implementation in LLVM Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified parameters during the LiveDebugValues pass, for the places where the Code Generation truncated live range of the parameters. The potential of the functionality goes beyond this, and it means we should be able to use the entry values even for modified parameters iff the modific...

...> value in the current frame. It relies on the call-site info provided, and the > more DW_AT_call_value generated, the more debug location inputs using > DW_OP_entry_value will be turned into real values. > > Current implementation in LLVM > > Currently in LLVM, we generate the DW_OP_entry_values *only* for unmodified > parameters during the LiveDebugValues pass, for the places where the Code > Generation truncated live range of the parameters. The potential of the > functionality goes beyond this, and it means we should be able to use the entry > values even for modified parame...

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

Thank you for your interest and comments! Please see my responses inline. On 2/7/19, 3:17 PM, "aprantl at apple.com on behalf of Adrian Prantl" <aprantl at apple.com> wrote: > On Feb 7, 2019, at 1:49 PM, Ananthakrishna Sowda (asowda) via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > Following is a proposal to improve location

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could

...copied/loaded from in a target-independent way? Would it be easier in earlier pre-regalloc MIR, or does that have the same problem because the instructions are already target-specific? > However, such analysis > might not be complete as current approach. It would not be able to > produce ‘DW_OP_entry_values’ in ‘DW_TAG_call_site_value’ expression of > call site parameter as a late pass. > > As example think of callee function that forwards its argument in > function call in entry block and never uses that argument again: > %vreg = COPY $rsi; -> > …. <no use of $r...

On 2/8/19, 7:15 AM, "paul.robinson at sony.com" <paul.robinson at sony.com> wrote: It's fantastic to see this happening! It'll be really nice to start seeing some DWARF 5 feature work (as opposed to the infrastructure stuff, which has its own benefits but doesn't help the end-user's debugging experience). A couple of questions below. --paulr

Hi, Following is a proposal to improve location coverage for Function parameters in LLVM. The patches for review will be posted soon. RFC: [DebugInfo] Improving Debug Information in LLVM to Recover Optimized-out Function Parameters Ananthakrishna Sowda(Cisco), asowda at cisco.com Nikola Prica (RT-RK/Cisco), nprica at rtrk.com Djordje Todorovic(RT-RK/Cisco), djtodorovic at rtrk.com Ivan Baev

> On Sep 10, 2019, at 6:15 AM, Djordje Todorovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end. > Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to > the DW_AT_call_all_calls. > > There is also

...l site parameters, we might be able to do all > necessary parameter's tracking in some separate MIR pass (not very late, > somewhere after ISEL). > >>> However, such analysis >>> might not be complete as current approach. It would not be able to >>> produce ‘DW_OP_entry_values’ in ‘DW_TAG_call_site_value’ expression of >>> call site parameter as a late pass. >>> >>> As example think of callee function that forwards its argument in >>> function call in entry block and never uses that argument again: >>> %vreg = COPY $rsi;...

Hello All, I was working on some dwarf-5 features and debugging optimized code support in clang and llvm. Noticed that, DW_TAG_call_site is supported in llvm middle-end. but clang is not emitting these. I was hoping, if someone could provide current status of these features and current status of dwarf-5 features in clang and llvm. That will be immensely helpful. Thanks! Sourabh. --------------

...sony.com Below is a non-exhaustive list of possible topics. Feel free to include any preferences and suggestions in your response. a. Line tables: 1. Can we fix is_stmt? 2. Is prologue_end reliable? 3. General stepping behaviour/quality. b. Variable locations: 1. The state of DW_OP_entry_values in llvm. 2. The state of the instruction-referencing DBG_VALUE work. 3. The state of multi-register DWARF expressions in llvm. 4. The possibility of salvaging out-of-liveness values using the 3 projects mentioned above. 5. Floating point debug-info quality in llvm. 6. Loop induc...

...call site parameters are the best solution > > let me know if that makes sense. > > Thanks, > adrian > >>> >>>>> However, such analysis >>>>> might not be complete as current approach. It would not be able to >>>>> produce ‘DW_OP_entry_values’ in ‘DW_TAG_call_site_value’ expression of >>>>> call site parameter as a late pass. >>>>> >>>>> As example think of callee function that forwards its argument in >>>>> function call in entry block and never uses that argument again: >...

Hello Djordje, Vedant, Thanks a lot for sharing information. I have a doubt, please consider the following simple test case- #include <iostream> int func(int* ptr){ std::cout << *ptr; return *ptr + 5; } int main(int argc, char** argv){ int a = 4; int* ptr_a = &a; int b = func(ptr_a); return 0; } commandline used -- bash$ clang++

....com> Below is a non-exhaustive list of possible topics. Feel free to include any preferences and suggestions in your response. a. Line tables: 1. Can we fix is_stmt? 2. Is prologue_end reliable? 3. General stepping behaviour/quality. b. Variable locations: 1. The state of DW_OP_entry_values in llvm. 2. The state of the instruction-referencing DBG_VALUE work. 3. The state of multi-register DWARF expressions in llvm. 4. The possibility of salvaging out-of-liveness values using the 3 projects mentioned above. 5. Floating point debug-info quality in llvm. 6. Loop induc...

...G_CALLSITEPARAM and producing it from ISEL phase (with dispatched IR part). Thanks, Nikola >>>>> >>>>>>> However, such analysis >>>>>>> might not be complete as current approach. It would not be able to >>>>>>> produce ‘DW_OP_entry_values’ in ‘DW_TAG_call_site_value’ expression of >>>>>>> call site parameter as a late pass. >>>>>>> >>>>>>> As example think of callee function that forwards its argument in >>>>>>> function call in entry block and never...