similar to: DebugInfo work contribution and update.

Displaying 20 results from an estimated 1000 matches similar to: "DebugInfo work contribution and update."

2019 Oct 09
3
DebugInfo work contribution and update.
Thanks, David for updating us. Regarding, mail address, can use anyone{@gmail or @amd}. but sourav0311 at gmail.com works best for me for mailing lists related stuff. Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. Primary motivation being GDB better handling of
2019 Oct 09
5
DebugInfo work contribution and update.
On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Welcome Sourabh, > > > > There are many bits of DWARF-5 that haven’t been implemented. > Got a short list, by chance? > I know there is currently no big push within Sony to “fill in the > corners” for v5, as we have been more focused on quality of debug info for > optimized
2020 Apr 15
4
Seeking clarification and way forward on limited scope variables.
Hi Sourabh, Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete. If at all possible, I’d /much/ rather we use the existing
2020 Jan 02
2
Query/Suggestions on upgrading macro infrastructure.
Hello Everyone, I would like to have your thoughts on this. Overview of the problem =================== While implementing support for the DWARFv5 debug_macro section support in LLVM. I came across these holes: - The macros infrastructure in CLANG/LLVM is inherently tied to a particular version(v4 macinfo). For instance, consider this snippet from CLANG:
2020 Apr 15
2
Seeking clarification and way forward on limited scope variables.
Hello Everyone, I need to have your thoughts on this. Consider the following test case -- ------------------------------------------- 1 int main(int Argc, char **Argv) { 2 int Local = 6; 3 printf("%d\n",Local); 4 5 { 6 printf("%d\n",Local); 7 int Local = 7; 8 printf("%d\n",Local); 9 }
2019 Nov 05
2
DWARFv5 DW_FORM_implicit_const support in LLVM
Hello folks, I was interested in the support we have for the attribute form DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some doubts wrt this. I noticed that support for this was put in here in 2017: https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571 >From what I could make out, the support for generating DW_FORM_implicit_const
2019 Oct 29
4
GitHub Access Request
Hi Tom, I do not have SVN account, for accessing LLVM. Thanks, Sourabh On Tue 29 Oct, 2019, 9:08 AM Tom Stellard, <tstellar at redhat.com> wrote: > On 10/26/2019 03:39 AM, Sourabh Singh Tomar wrote: > > Hi All, > > > > I recently requested Chris regarding commit access to LLVM. > > He asked me to wait till the GitHub migration completes and then ask in >
2020 Nov 12
2
[DebugInfo]Crash during building openmpi4.0.0
Hi folks, While building openmpi.4.0.0(Optimized debug build), using trunk clang we encountered a crash(assertion failure). Initially assertion seems trivial: [...] void llvm::DwarfExpression::addFragmentOffset(const llvm::DIExpression*): Assertion `FragmentOffset >= OffsetInBits && "overlapping or duplicate fragments"' failed. [...] But, narrowing to RC. We discovered
2020 Sep 01
4
Filename's in DIBuileder
Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate DIFile entries, but not yet able to reproduce a .debug_line section with multiple directory entries. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar, Sourabh Singh via llvm-dev Sent: Tuesday, September 1, 2020 1:07 PM To: Umesh Kalappa <umesh.kalappa0 at gmail.com>; cfe-dev at
2019 Oct 10
2
DebugInfo work contribution and update.
On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > Ah, thanks for the list - mostly I'm interested in cases where Clang's > > output is not valid DWARFv5 when requested - the new features DWARFv5 > > enables/allows but doesn't require are lower priority to me. Which I > > don't think too much is left - DWARFv5
2020 Jan 13
2
Attempt to build MLIR.
These errors seem pretty pervasive for me on a clean build. It appears that it arises because when tablegen'd headers are included in a .h file, every place where that .h file is used needs a dependency on the corresponding IncGen targets. This seems broken in the short term and unmaintainable in the long term. There really needs to be a way of automatically generating the right
2019 Sep 11
3
Dwarf - 5 features in clang and llvm
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++
2019 Dec 24
2
Attempt to build MLIR.
Hello everyone, Since MLIR landed today. I'm trying to build it using cmake ../llvm/ -DCMAKE_BUILD_TYPE=RELEASE -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ALL_PROJECTS="clang;lld;lldb;mlir" -DBUILD_SHARED_LIBS=ON -DCLANG_DEFAULT_LINKER:STRING=lld and also by adding -DLLVM_ALL_PROJECTS. It's giving this compilation error -- Building CXX object
2019 Sep 13
2
DWARF-5 Supported languages Tags C++03, C++11,C++14
Hello Everyone, I'm working on providing support for New Language Tags, prescribed in DWARF-5. DW_LANG_C_plus_plus_03 DW_LANG_C_plus_plus_11 DW_LANG_C_plus_plus_14 While, C++11 and C++14, is defined and can be emitted by Frontend. "include/clang/Basci/LangStandard.h" CPlusPlus = (1 << 5), CPlusPlus11 = (1 << 6), CPlusPlus14 = (1 << 7), CPlusPlus17 = (1 <<
2020 Apr 01
2
Question WRT llvm.dbg.value
> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that
2019 Sep 10
2
Dwarf - 5 features in clang and llvm
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. --------------
2020 Mar 30
3
Question WRT llvm.dbg.value
Hello Everyone, I have general question WRT llvm.dbg.value intrinsic function semantics. Under what circumstances should a frontend choose to emit(at -O0(No optimization)) llvm.dbg.value for a local variable. I saw some debuginfo code in flang(older one), sort of it choose to emit *llvm.dbg.value* for *every load operation* happening on a *local variable*. And as noted below in IR snippet it
2019 Sep 10
2
Dwarf - 5 features in clang and llvm
> 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
2020 Mar 30
3
Question WRT llvm.dbg.value
> On Mar 30, 2020, at 4:13 AM, Jeremy Morse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > On Mon, Mar 30, 2020 at 8:09 AM Sourabh Singh Tomar via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Under what circumstances should a frontend choose to emit(at -O0(No optimization)) llvm.dbg.value for a local variable. >> >> I
2020 Mar 31
2
Question WRT llvm.dbg.value
> On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > >> > My understanding is that this isn't correct: dbg.declare specifies the >> memory address of a variable for the whole lifetime of the function, >> whereas dbg.value (and dbg.addr) specify the value/address until the >> next debug intrinsic. Mixing these two kinds