From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: Symbol can't be found unless type 'tab'
Date: Wed, 12 Sep 2012 08:07:00 -0000 [thread overview]
Message-ID: <20120912080639.GA16010@host2.jankratochvil.net> (raw)
In-Reply-To: <50503D6C.6070704@codesourcery.com>
[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]
On Wed, 12 Sep 2012 09:44:44 +0200, Yao Qi wrote:
> On 09/10/2012 09:18 PM, Jan Kratochvil wrote:
> >On Mon, 10 Sep 2012 14:51:29 +0200, Yao Qi wrote:
> >>> <1><2c>: Abbrev Number: 3 (DW_TAG_variable)
> >>> <2d> DW_AT_name : i
> >>> <2f> DW_AT_type : <0x23>
> >>> <33> DW_AT_location : 0x0 (location list)
> >I guess because GDB does not like such complicated location expression for
> >glboal variables.
>
> Jan, thanks for the pointer.
>
> The "symptom" is symbol is not found in psymtab, but in symtab when
> I press 'tab' which triggers converting psymtab to symtab. I wonder
> why symbol 'i' is *not* included in psymtab.
Because it has the complex location I suggested above.
> Examine the source of
> dwarf2read.c:add_partial_symbol, especially the case block for
> 'DW_TAG_variable', gives me some clue, and I add attribute
> DW_AT_external to symbol 'i' like this,
>
> <1><33>: Abbrev Number: 3 (DW_TAG_variable)
> <34> DW_AT_name : i
> <36> DW_AT_type : <0x2a>
> <3a> DW_AT_external : 1 <--- here
> <3b> DW_AT_location : 0x0 (location list)
>
> and then symbol 'i' can be found by GDB without typing extra 'tab'.
It is difficult to talk about the problem when you have not provided the
testcase, I have provided mine now.
But DW_AT_external is not significant to GDB as GDB can display even static
variables, even when they are not in current CU.
It is good to verify 'maintenance info symtabs' is empty during these
experiments, when one tries to print the variable.
I am very sure that this complex DW_AT_location is not properly supported by
psymtabs in GDB, this is one of the reasons I was doing the fix and its later
undo as I referenced in the previous mail.
Why didn't use just normal DWARF block, instead of the location list?
This part does not matter for your testcase and it will work with GDB.
Jan
[-- Attachment #2: i.c --]
[-- Type: text/plain, Size: 7 bytes --]
int i;
[-- Attachment #3: i.s --]
[-- Type: text/plain, Size: 2693 bytes --]
.file "i.c"
.text
.Ltext0:
.comm i,4,4
.Letext0:
.file 1 "i.c"
.section .debug_info,"",@progbits
.Ldebug_info0:
.long 1f - 2f # Length of Compilation Unit Info
2:
.value 0x4 # DWARF version number
.long .Ldebug_abbrev0 # Offset Into Abbrev. Section
.byte 0x8 # Pointer Size (in bytes)
.uleb128 0x1 # (DIE (0xb) DW_TAG_compile_unit)
.long .LASF0 # DW_AT_producer: "GNU C 4.6.3 20120306 (Red Hat 4.6.3-2) -mtune=generic -march=x86-64 -g"
.byte 0x2 # DW_AT_language
.ascii "i.c\0" # DW_AT_name
# .long .LASF1 # DW_AT_comp_dir: "/home/jkratoch/t"
# .long .Ldebug_line0 # DW_AT_stmt_list
.uleb128 0x2 # (DIE (0x1d) DW_TAG_variable)
.ascii "i\0" # DW_AT_name
# .byte 0x1 # DW_AT_decl_file (i.c)
# .byte 0x1 # DW_AT_decl_line
.long die30-.Ldebug_info0 # DW_AT_type
# DW_AT_external
.uleb128 0x9 # DW_AT_location
.byte 0x3 # DW_OP_addr
.quad i
die30:
.uleb128 0x3 # (DIE (0x30) DW_TAG_base_type)
.byte 0x8 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.ascii "int\0" # DW_AT_name
.byte 0 # end of children of DIE 0xb
1:
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.uleb128 0x1 # (abbrev code)
.uleb128 0x11 # (TAG: DW_TAG_compile_unit)
.byte 0x1 # DW_children_yes
.uleb128 0x25 # (DW_AT_producer)
.uleb128 0xe # (DW_FORM_strp)
.uleb128 0x13 # (DW_AT_language)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
# .uleb128 0x1b # (DW_AT_comp_dir)
# .uleb128 0xe # (DW_FORM_strp)
# .uleb128 0x10 # (DW_AT_stmt_list)
# .uleb128 0x17 # (DW_FORM_sec_offset)
.byte 0
.byte 0
.uleb128 0x2 # (abbrev code)
.uleb128 0x34 # (TAG: DW_TAG_variable)
.byte 0 # DW_children_no
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
# .uleb128 0x3a # (DW_AT_decl_file)
# .uleb128 0xb # (DW_FORM_data1)
# .uleb128 0x3b # (DW_AT_decl_line)
# .uleb128 0xb # (DW_FORM_data1)
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
# .uleb128 0x3f # (DW_AT_external)
# .uleb128 0x19 # (DW_FORM_flag_present)
.uleb128 0x2 # (DW_AT_location)
.uleb128 0x18 # (DW_FORM_exprloc)
.byte 0
.byte 0
.uleb128 0x3 # (abbrev code)
.uleb128 0x24 # (TAG: DW_TAG_base_type)
.byte 0 # DW_children_no
.uleb128 0xb # (DW_AT_byte_size)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3e # (DW_AT_encoding)
.uleb128 0xb # (DW_FORM_data1)
.uleb128 0x3 # (DW_AT_name)
.uleb128 0x8 # (DW_FORM_string)
.byte 0
.byte 0
.byte 0
.section .debug_line,"",@progbits
.Ldebug_line0:
.section .debug_str,"MS",@progbits,1
.LASF0:
.string "GNU C 4.6.3 20120306 (Red Hat 4.6.3-2) -mtune=generic -march=x86-64 -g"
.LASF1:
.string "/home/jkratoch/t"
.ident "GCC: (GNU) 4.6.3 20120306 (Red Hat 4.6.3-2)"
.section .note.GNU-stack,"",@progbits
next prev parent reply other threads:[~2012-09-12 8:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 12:52 Yao Qi
2012-09-10 13:18 ` Jan Kratochvil
2012-09-12 7:45 ` Yao Qi
2012-09-12 8:07 ` Jan Kratochvil [this message]
2012-09-12 11:34 ` Yao Qi
2012-09-12 12:33 ` Jan Kratochvil
2012-09-12 13:37 ` Yao Qi
2012-09-12 13:45 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120912080639.GA16010@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox