Displaying 20 results from an estimated 1000 matches similar to: "RFC: Supporting all entities declared in lexical scope in LLVM debug info"
2016 Jan 19
2
RFC: Supporting all entities declared in lexical scope in LLVM debug info
On Mon, Dec 14, 2015 at 7:01 AM, Aboud, Amjad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I verified that GDB 7.10 does support “DW_AT_abstract_origin” attribute on
> “DW_TAG_lexical_block”.
>
I take it you mean that it does the right thing, finding the direct
children of the abstract block when stepping into the inlined subroutine,
etc?
& this was a
2016 Mar 23
1
Clang/LLVM producing incomplete & erroneous debug information
Hi everyone,
I'm trying to get debug information for a C/pthreads application, but it
seems like clang/LLVM are producing limited & erroneous debugging
information. I've attached a simple test example to reproduce the problem
-- I'm using clang/LLVM 3.7.1 built from source on Ubuntu 14.04.
I compile the attached file with:
$ clang -O1 -g test.c -lpthread
If I run:
$ readelf
2019 Nov 29
4
DW_OP_implicit_pointer design/implementation in general
Let me try to summarize the implementation first.
At the moment, there are two branches.
1. When an existing variable is optimized out and that variable is used to
get the de-refereced value, pointed to by another pointer/reference
variable.
Such cases are being addressed using Dwarf expression
DW_OP_implicit_pointer as de-referenced value of a pointer can be seen
implicitly (using another
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
Sorry, this is the attachment.
2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>:
> Thank you.
>
> Here is an example and the attchment contains extra files including object
> file and executable file.
> I want to print for example the value of "a", but lldb command "frame
> variable a" displays "0" and so does "b", and
2014 Feb 18
1
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for.
Greg Clayton
On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote:
> Hi, all
>
> I
2014 Feb 18
4
[LLVMdev] How is variable info retrieved in debugging for executables generated by llvm backend?
Hi, all
I ported llvm backend and lldb recently. Both tools can basically work.
lldb is able to debug programs in asm style and frame unwinding is OK.
But "frame variable XX" does not work because lldb is not able to determine
the address of
XX from debug info.
Can someone give any clue?
Thanks in advance.
--
杨勇勇 (Yang Yong-Yong)
-------------- next part --------------
An HTML
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 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 }
2016 Dec 15
1
distinct DISubprograms hindering sharing inlined subprogram descriptions
On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Branching off from a discussion of improvements to DIGlobalVariable
> representations that Adrian's working on - got me thinking about related
> changes that have
2020 May 13
2
[Debuginfo][DWARF][LLD] Remove obsolete debug info in lld.
Hi David, Excuse me for delayed answer. It took some time to prepare. Please, find the answers bellow...
>Broad question: Do you have any specific motivation/users/etc in implementing this (if you can speak about it)?
> - it might help motivate the work, understand what tradeoffs might be suitable for you/your users, etc.
There are two general requirements:
1) Remove (or clean) invalid
2018 Mar 23
2
Question about debug information for global variables
On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
>
>> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>>
>> Adrian,
>>
>> Thanks for a quick reply!
>>
>> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>>
>>>
>>>>
2016 May 08
2
Debug info scope of explicit casting type does not seem correct
That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*).
This is the code that creates DW_TAG_subprogram:
DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) {
...
// DW_TAG_inlined_subroutine may refer
2018 Mar 23
0
Question about debug information for global variables
On Thu, Mar 22, 2018 at 5:13 PM, Roman Levenstein via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Thu, Mar 22, 2018 at 4:51 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>
>>
>>> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>>>
>>> Adrian,
>>>
>>> Thanks for a quick reply!
2020 May 08
4
[Debuginfo][DWARF][LLD] Remove obsolete debug info in lld.
Folks, we work on optimization of binary size and improvement of debug info quality.
To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected.
When the linker does garbage collection, a lot of abandoned debug info is left behind.
Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage
2018 Mar 22
2
Question about debug information for global variables
Adrian,
Thanks for a quick reply!
On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
>
>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>>
>> Hi,
>>
>> I'm trying to achieve the following:
>>
>> - I have a global variable BaseAddress that holds the base address of
>> a
2018 Nov 01
4
Fwd: RFC: Adding debug information to LLVM to support Fortran
*From:* flang-dev <flang-dev-bounces at lists.flang-compiler.org> *On Behalf
Of *Eric Schweitz (PGI)
*Sent:* Thursday, November 01, 2018 1:02 PM
*To:* flang-dev at lists.flang-compiler.org
*Subject:* [Flang-dev] RFC: Adding debug information to LLVM to support
Fortran
In order to support debugging in the Flang project, work has been done to
extend LLVM debug information for the Fortran
2018 Mar 22
0
Question about debug information for global variables
> On Mar 22, 2018, at 4:47 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>
> Adrian,
>
> Thanks for a quick reply!
>
> On Thu, Mar 22, 2018 at 4:22 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>
>>
>>> On Mar 22, 2018, at 4:08 PM, Roman Levenstein <romixlev at gmail.com> wrote:
>>>
>>> Hi,
>>>
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
I was told that my writeup lacked an example and details so I reproduced
the code that X uses and I was able to boil down the issue to a couple
of lines of code. Sorry again for the length of this email.
Code was compiled on OpenBSD with clang 3.0-release.
========================================================================
With -O0 which works as X expects:
2019 Dec 10
2
aarch64 do not generate debug info for tls var
Hi Devs,
consider below testcase
$cat test.c
__thread int mtls=1;
void foo(){
mtls++;
}
it emits this debug info for mtls
0x0000002a: DW_TAG_variable
DW_AT_name ("mtls")
DW_AT_type (0x00000035 "int")
DW_AT_external (true)
DW_AT_decl_file ("test.c")
DW_AT_decl_line (1)
2019 Dec 10
2
aarch64 do not generate debug info for tls var
GCC's behavior matches LLVM.
so should we leave it?
On Tue, Dec 10, 2019 at 12:54 PM David Blaikie <dblaikie at gmail.com> wrote:
> What does GCC do?
>
> On Mon, Dec 9, 2019 at 10:25 PM kamlesh kumar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Devs,
>>
>> consider below testcase
>> $cat test.c
>> __thread int mtls=1;