This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/18436] Can't print dynamically allocated global array


https://sourceware.org/bugzilla/show_bug.cgi?id=18436

--- Comment #5 from Keith Seitz <keiths at redhat dot com> ---
(In reply to stanton from comment #2)
> Thanks for the response, Keith First, Iâm running OS X 10.10.3.
> 
> Test 1: MacPorts versions of gdb and gcc
> gdb version = GNU gdb (GDB) 7.7.1
> gcc version = gcc version 4.9.2 (MacPorts gcc49 4.9.2_1) 
> 
> (gdb) print vec[0]
> cannot subscript something of type `<data variable, no debug info>'
> (gdb) info var ^vec$
> All variables matching regular expression "^vec$":
> 
> Non-debugging symbols:
> 0x0000000100001028  vec
> 

Considering you have source files and can step through your program, this tells
me that there is a debug info problem concerning the global variable vec or
there is some obscure bug in gdb preventing this from working.

I have some vague recollection of custom Apple DWARF extensions making their
way into GCC for MacOS, but not GDB. That might explain why LLDB can
successfully inspect the variable.

Does "readelf -w" (does that exist on Mac?) show any output DIEs?

For example, for the test case associated with this bug,

$ readelf -w main | grep producer
     <c>   DW_AT_producer    : (indirect string, offset: 0xb6): GNU C 4.9.2
20150212 (Red Hat 4.9.2-6) -mtune=generic -march=x86-64 -g  
    DW_AT_producer     DW_FORM_strp

Other than the fact that we have debug DIEs, we can also see the "-g" was
passed to GCC to output debug info.

Also, what is the debug info for "vec" (if any)? In my build of the test, I
have:
 <1><d7>: Abbrev Number: 8 (DW_TAG_variable)
    <d8>   DW_AT_name        : vec      
    <dc>   DW_AT_decl_file   : 1        
    <dd>   DW_AT_decl_line   : 4        
    <de>   DW_AT_type        : <0xec>   
    <e2>   DW_AT_external    : 1        
    <e2>   DW_AT_location    : 9 byte block: 3 50 10 60 0 0 0 0 0      
(DW_OP_addr: 601050)

A (not satisfactory IMO) workaround is to tell gdb what "vec" is:
(gdb) file ~/tmp/18436.nodebug
(gdb) start
Temporary breakpoint 1 at 0x4005ca
Starting program: /home/keiths/tmp/18436.nodebug 

Temporary breakpoint 1, 0x00000000004005ca in main ()
(gdb) ni 50
Item 0 =               0
0x000000000040062b in main ()
(gdb) p vec[0]
cannot subscript something of type `<data variable, no debug info>'
(gdb) p ((double*)vec)[0]
$1 = 0
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]