Displaying 20 results from an estimated 34 matches for "dw_at_external".
2018 Mar 23
2
Question about debug information for global variables
...nt:
>>
>> With deref:
>> 0x00000032: DW_TAG_variable [2]
>> DW_AT_name [DW_FORM_strp] (
>> .debug_str[0x0000001d] = "var1")
>> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
>> DW_AT_external [DW_FORM_flag_present] (true)
>> DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0
>> 2e 00 00 00 00 00 00 06 10 00 22 )
>>
>>
>> Without deref:
>> 0x00000032: DW_TAG_variable [2]
>> DW_AT_name [DW_FORM_strp]...
2018 Mar 23
0
Question about debug information for global variables
...; With deref:
>>> 0x00000032: DW_TAG_variable [2]
>>> DW_AT_name [DW_FORM_strp] (
>>> .debug_str[0x0000001d] = "var1")
>>> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
>>> DW_AT_external [DW_FORM_flag_present] (true)
>>> DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0
>>> 2e 00 00 00 00 00 00 06 10 00 22 )
>>>
>>>
>>> Without deref:
>>> 0x00000032: DW_TAG_variable [2]
>>> DW_...
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
...# DW_AT_encoding
.byte 4 # DW_AT_byte_size
.byte 3 # Abbrev [3] 0x63:0x18 DW_TAG_variable
.ascii "something" # DW_AT_name
.byte 0
.long 92 # DW_AT_type
.byte 1 # DW_AT_external
.byte 1 # DW_AT_decl_file
.byte 6 # DW_AT_decl_line
.byte 5 # DW_AT_location
.byte 3
.long something
.byte 3 # Abbrev [3] 0x7b:0x1d DW_TAG_variable
.ascii "something_else" # DW_AT_name
....
2012 Feb 24
1
[LLVMdev] DW_AT_inline not present in assembly for an inlined inline function
...se fails because, DW_AT_inline is not present in assembly output.
Could anyone let me know why DW_AT_inline is not emitted with Clang
compiled assembly output?
I am aware that Clang uses C99 mode by default.
In case of GCC,
.uleb128 0x2 @ (DIE (0x25) DW_TAG_subprogram)
.byte 0x1 @ DW_AT_external
.ascii "t\0" @ DW_AT_name
.byte 0x1 @ DW_AT_decl_file (test.h)
.byte 0x1 @ DW_AT_decl_line
.4byte 0x30 @ DW_AT_type
.byte 0x3 @ DW_AT_inline
In case of Clang,
.byte 4 @ Abbrev [4] 0x87:0xa DW_TAG_sub...
2018 Mar 22
2
Question about debug information for global variables
...=all myobjectfile.o
The DW_AT_location values are different:
With deref:
0x00000032: DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp] (
.debug_str[0x0000001d] = "var1")
DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
DW_AT_external [DW_FORM_flag_present] (true)
DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0
2e 00 00 00 00 00 00 06 10 00 22 )
Without deref:
0x00000032: DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp] (
.debug_str[0x0000001d] = "var1")...
2018 Mar 22
0
Question about debug information for global variables
...location values are different:
>
> With deref:
> 0x00000032: DW_TAG_variable [2]
> DW_AT_name [DW_FORM_strp] (
> .debug_str[0x0000001d] = "var1")
> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
> DW_AT_external [DW_FORM_flag_present] (true)
> DW_AT_location [DW_FORM_exprloc] (<0xd> 03 b0
> 2e 00 00 00 00 00 00 06 10 00 22 )
>
>
> Without deref:
> 0x00000032: DW_TAG_variable [2]
> DW_AT_name [DW_FORM_strp] (
> .debug_str[0x00000...
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)
which does not contain DW_AT_Location.
Currently, aarch64 does not emit DW_AT_Location for TLS variables.
I could see at this line, it says some restriction in aarch64 elf abi.
https://github.com/llvm...
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
...fo_string3 # DW_AT_name
> .byte 1 # DW_AT_decl_file
> .byte 2 # DW_AT_decl_line
> # DW_AT_prototyped
> .int 127 # DW_AT_type
> # DW_AT_external
> .int Lfunc_begin0 # DW_AT_low_pc
> .int Lfunc_end0 # DW_AT_high_pc
> .byte 2 # DW_AT_frame_base
> .byte 144
> .byte 60
> .byte 3 # Abbrev [3] 0x38:0xe
> DW_TAG_formal_parameter
> .int Linfo_string5...
2016 Mar 23
1
Clang/LLVM producing incomplete & erroneous debug information
...te block: 57 (DW_OP_reg7 (rsp))
<b6> DW_AT_name : (indirect string, offset: 0xaf): main
<ba> DW_AT_decl_file : 1
<bb> DW_AT_decl_line : 16
<bc> DW_AT_prototyped : 1
<bc> DW_AT_type : <0x3f>
<c0> DW_AT_external : 1
<c0> Unknown AT value: 3fe1: 1
<2><c0>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<c1> DW_AT_location : 0x23 (location list)
<c5> DW_AT_name : (indirect string, offset: 0xc2): argc
<c9> DW_AT_decl_file : 1
<...
2017 Apr 04
2
GDB doesn't work with IR-originated debug info
...[DW_FORM_data4] (0x000002b4)
DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 )
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] =
"FB_FPUMP at HORIZONTAL")
DW_AT_type [DW_FORM_ref_addr] (*0x0000000000000296*)
DW_AT_external [DW_FORM_flag_present] (true)
There are lots of subprogram records like this.
Any ideas what may be done to fix that?
My debugger config:
GNU gdb (GDB) 7.10.1
This GDB was configured as "i686-w64-mingw32".
OS : Win7 64-bit
--
Best regards,
Alexey Zasenko
-------------- next part -...
2019 Dec 10
2
aarch64 do not generate debug info for tls var
...> 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)
>>
>> which does not contain DW_AT_Location.
>>
>> Currently, aarch64 does not emit DW_AT_Location for TLS variables.
>> I could see at this line, it says...
2018 Nov 26
2
Source locations missing when using xray-account
...DW_AT_high_pc (0x0000000000420817)
DW_AT_frame_base (DW_OP_reg7 RSP)
DW_AT_linkage_name ("fqux")
DW_AT_name ("fqux")
DW_AT_decl_file ("TODO/llvm.hs")
DW_AT_decl_line (8)
DW_AT_external (true)
I suspect this is a problem with the DWARF information as when I try
to use `llvm-symboliser` with address 0x00000000004207c8 as retrieved
from the above paste, the source location is also not reported.
So, can anyone give me some practical advice about how to troubleshoot
this problem/va...
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
2020 Apr 22
2
Debug symbols are missing in elf
...r1))
> > <31> DW_AT_name : (indirect string, offset: 0x0): clang
> > version 8.0.1
> > <35> DW_AT_decl_file : 1
> > <36> DW_AT_decl_line : 51
> > <37> DW_AT_type : <0x66>
> > <3b> DW_AT_external : 1
> >
> > -Nagaraju
>
2014 Aug 28
2
[LLVMdev] Minimizing -gmlt
...e.
>
>>
>> So here's an example of some of my ideas about minimized debug info. I'm
>> wondering if I'm right about what's needed for backtracing.
>>
>> I've removed uninteresting things, like DW_AT_accessibility (which is a
>> bug anyway), DW_AT_external (there's no reason symbolication needs that, is
>> there?), but also less obviously uninteresting things like DW_AT_frame_base
>> (the location of the frame pointer - is that needed for symbolication?)
>>
>
> We don't use DW_AT_accessibility and DW_AT_external.
>...
2020 Apr 21
2
Debug symbols are missing in elf
...DW_AT_frame_base : 1 byte block: 51 (DW_OP_reg1 (r1))
<31> DW_AT_name : (indirect string, offset: 0x0): clang
version 8.0.1
<35> DW_AT_decl_file : 1
<36> DW_AT_decl_line : 51
<37> DW_AT_type : <0x66>
<3b> DW_AT_external : 1
-Nagaraju
On Mon, Apr 20, 2020 at 1:26 PM James Henderson
<jh7370.2008 at my.bristol.ac.uk> wrote:
>
> It looks to me like the DWARF is corrupt somehow. What happens if you try using llvm-objdump (as opposed to a GNU-based objdump) to dump the information? What warning(s) do yo...
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
2018 Dec 03
2
Source locations missing when using xray-account
...DW_AT_frame_base (DW_OP_reg7 RSP)
>> DW_AT_linkage_name ("fqux")
>> DW_AT_name ("fqux")
>> DW_AT_decl_file ("TODO/llvm.hs")
>> DW_AT_decl_line (8)
>> DW_AT_external (true)
>>
>> I suspect this is a problem with the DWARF information as when I try
>> to use `llvm-symboliser` with address 0x00000000004207c8 as retrieved
>> from the above paste, the source location is also not reported.
>>
Yes, this is the issue. Getting llvm-sym...
2020 Apr 23
2
Debug symbols are missing in elf
...: (indirect string, offset: 0x0): clang
>> > > version 8.0.1
>> > > <35> DW_AT_decl_file : 1
>> > > <36> DW_AT_decl_line : 51
>> > > <37> DW_AT_type : <0x66>
>> > > <3b> DW_AT_external : 1
>> > >
>> > > -Nagaraju
>> >
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
2014 Aug 27
6
[LLVMdev] Minimizing -gmlt
...possibly just those
that have functions inlined into them.
So here's an example of some of my ideas about minimized debug info. I'm
wondering if I'm right about what's needed for backtracing.
I've removed uninteresting things, like DW_AT_accessibility (which is a bug
anyway), DW_AT_external (there's no reason symbolication needs that, is
there?), but also less obviously uninteresting things like DW_AT_frame_base
(the location of the frame pointer - is that needed for symbolication?)
Also I've made a frontend (for now) change (see mgmlt_clang.diff) to omit
the data that causes...