From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) by sourceware.org (Postfix) with ESMTPS id 658853857816 for ; Sun, 27 Jun 2021 16:11:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 658853857816 Received: by mail-ua1-x929.google.com with SMTP id f34so5863416uae.4 for ; Sun, 27 Jun 2021 09:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vqhVGPyBTYMpiqPuo0K4ExPGl7U9vW/M8YpYFd9GCX0=; b=XXWeND9MCQ8/ImXUkgdlnimDUVwTjLIbT85PtjUYzVjb64u9BX5YipNelPIV1fTrKU Pwf49bjsa/owLHyJoUwFtQqdvzjLCDJ5+LeMYSHefofhlmB2hJuu0Tah5zABwnMPr98Y 0JbwElRZPDZgdbyTOuP84oqDU2sDOTEDXtAdOVbADXqQOq2JBj4+htcmcQiGjIlZ01Kd 9M3ibZa7FM59wSmSo+tI514dLlk3Kt5d6QUoHMDHfd4OZ9Qac7WyM5JbxlGQxJzPjiUM ycSp1ZnUJfTclN4nc2ca5M4jdBdfTmdnjIfRsid1hICG4c8mHZMIbcERgbpGJ/IPpW14 ixiw== X-Gm-Message-State: AOAM531VUznb2Uv1Kv9wCvLQW6QHnNzLVQp61GKI41G3HAzfNKVQXQDx ppXnK9s/beQ+ZMy09riuw7H+ndxp1sFJcPwXdaE= X-Google-Smtp-Source: ABdhPJxa7faJDqMSaqgpIo2JNj5582ZCZX0mOPE+hm+60IyTYUbksqQHzi6xUHrwi1fDJlBcNSFF1m/Xq854l01QeAc= X-Received: by 2002:a9f:238b:: with SMTP id 11mr13163845uao.91.1624810281648; Sun, 27 Jun 2021 09:11:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Blaikie Date: Sun, 27 Jun 2021 09:11:10 -0700 Message-ID: Subject: Re: gdb unable to print alias variable To: kamlesh kumar Cc: Simon Marchi , gdb X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 16:11:25 -0000 On Sat, Jun 26, 2021 at 8:11 PM kamlesh kumar wrote: > David, > I haven't updated the llvm review yet, but here is the diff I have used > https://reviews.llvm.org/differential/diff/354719/ Ah, thanks. I tried this patch and it seems to work fine with gdb for me? oooh... it works if the debugger's context is in the translation unit with the using declaration - if you're stepped into (or haven't started the program) some function in another translation unit, the using decl isn't in scope and so isn't used: (gdb) ptype newname type = (gdb) start Temporary breakpoint 1 at 0x401114: file alias.cpp, line 3. Starting program: /usr/local/google/home/blaikie/dev/scratch/a.out p Temporary breakpoint 1, main () at alias.cpp:3 3 int main(){} (gdb) ptype newname type = int That's probably appropriate behavior for gdb to interpret a using declaration, as being local to the translation unit (though I don't think C++ technically defines it that way - I think even a using declaration is considered to be a name for the whole program, but it's the sort of ODR violation that's /super/ common and hard to think of a reason why it'd break any implementation). This might explain GCC's choice of representing an alias with a variable rather than an imported declaration - so that it would the debug info would be externally visible in other translation units. > > On Sun, Jun 27, 2021 at 7:19 AM David Blaikie wrote: > > > > imported declaration can also be used to bring a single name from a > namespace: > > > > namespace ns { > > > > int i = 32; > > > > } > > > > using ns::i; > > > > int main() { > > > > } > > > > 0x0000002a: DW_TAG_namespace > > > > DW_AT_name ("ns") > > > > > > 0x0000002f: DW_TAG_variable > > > > DW_AT_name ("i") > > > > DW_AT_type (0x00000045 "int") > > > > DW_AT_external (true) > > > > DW_AT_decl_file > ("/usr/local/google/home/blaikie/dev/scratch/import.cpp") > > > > DW_AT_decl_line (2) > > > > DW_AT_location (DW_OP_addr 0x404028) > > ... > > > > > > 0x0000004c: DW_TAG_imported_declaration > > > > DW_AT_decl_file > ("/usr/local/google/home/blaikie/dev/scratch/import.cpp") > > > > DW_AT_decl_line (4) > > > > DW_AT_import (0x0000002f) > > > > > > Which looks closer to the alias situation - I would guess the only > reason the alias imported_declaration isn't working as intended is that > maybe GDB looks at the symbol table first and since it finds a symbol with > that name it favors the symbol (but finds no debug info describing it and > complains about that) > > > > Let's see if I hand modify the DWARF so there's no symbol, but otherwise > an imported declaration that looks pretty close to what would be produced > in the alias situation... > > > > Hmm, that seems to work correctly for me. Let me try Kamlesh's original > patch... > > > > Yeah, using the example code below, and the D103131 patch... hmm, OK the > current version of the patch only does DW_TAG_variables, and the first > version of the patch does DW_TAG_variables /and/ a > DW_TAG_imported_declaration without a name - that doesn't look like the > DWARF shown at the start of this thread. > > > > Kamlesh - which version of the patch are you testing that produced the > DWARF shown in the start of this thread? Because hand-crafted DWARF/file > that I tried that used an imported declaration as shown above, seemed to > work OK for me with lldb. So I'm not sure what's making your experience > different from mine. > > > > - Dave > > > > On Fri, Jun 25, 2021 at 7:50 PM Simon Marchi via Gdb > wrote: > >> > >> > >> > >> On 2021-06-23 8:34 p.m., kamlesh kumar via Gdb wrote: > >> > Hi Devs, > >> > Currently clang does not produce debug info for alias variables, I am > >> > working on this feature, by having DW_TAG_imported_declaration for > >> > alias variable but gdb does not work with this. > >> > below is demonstration > >> > > >> > consider this testcase, > >> > ----------- > >> > int oldname = 1; > >> > extern int newname attribute((alias("oldname"))); > >> > int main(){} > >> > --------------------- > >> > $clang test.c -g > >> > $gdb a.out > >> > (gdb) pt oldname > >> > type = int > >> > (gdb) pt newname > >> > type = > >> > (gdb) p newname > >> > 'newname' has unknown type; cast it to its declared type > >> > > >> > Here is debug info in ./a.out by clang > >> > dumped debug info (using llvm-dwarfdump) > >> > test.o: file format elf64-x86-64 > >> > > >> > .debug_info contents: > >> > 0x00000000: Compile Unit: length = 0x00000067, format = DWARF32, > >> > version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at > >> > 0x0000006b) > >> > > >> > 0x0000000b: DW_TAG_compile_unit > >> > DW_AT_producer ("clang version 13.0.0 > >> > (git@github.com:llvm/llvm-project.git > >> > 4cd7169f5517167ef456e82c6dcae669bde6c725)") > >> > DW_AT_language (DW_LANG_C99) > >> > DW_AT_name ("test.c") > >> > DW_AT_stmt_list (0x00000000) > >> > DW_AT_comp_dir > ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin") > >> > DW_AT_low_pc (0x0000000000000000) > >> > DW_AT_high_pc (0x0000000000000008) > >> > > >> > 0x0000002a: DW_TAG_variable > >> > DW_AT_name ("oldname") > >> > DW_AT_type (0x0000003f "int") > >> > DW_AT_external (true) > >> > DW_AT_decl_file > >> > ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c") > >> > DW_AT_decl_line (1) > >> > DW_AT_location (DW_OP_addr 0x0) > >> > > >> > 0x0000003f: DW_TAG_base_type > >> > DW_AT_name ("int") > >> > DW_AT_encoding (DW_ATE_signed) > >> > DW_AT_byte_size (0x04) > >> > > >> > 0x00000046: DW_TAG_imported_declaration > >> > DW_AT_decl_file > >> > ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c") > >> > DW_AT_decl_line (2) > >> > DW_AT_import (0x0000002a) > >> > DW_AT_name ("newname") > >> > > >> > 0x00000051: DW_TAG_subprogram > >> > DW_AT_low_pc (0x0000000000000000) > >> > DW_AT_high_pc (0x0000000000000008) > >> > DW_AT_frame_base (DW_OP_reg6 RBP) > >> > DW_AT_name ("main") > >> > DW_AT_decl_file > >> > ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c") > >> > DW_AT_decl_line (3) > >> > DW_AT_type (0x0000003f "int") > >> > DW_AT_external (true) > >> > > >> > 0x0000006a: NULL > >> > > >> > Even though the newname has desired info, gdb is unable to print the > >> > value or type of the newname. > >> > I would like to know whether this is a bug in gdb, or debug info > >> > itself is wrong(because of DW_TAG_imported_declaration for newname)? > >> > Any other viable path to address alias variable debugging will be > appreciated. > >> > >> My intuition, from looking at where DW_TAG_imported_declaration can be > >> found in dwarf2/read.c, is that support for DW_TAG_imported_declaration > >> was done with namespace imports in mind. For example, with this code: > >> > >> namespace foo > >> { > >> int x = 11; > >> }; > >> > >> namespace bar = foo; > >> > >> int main() { > >> return bar::x; > >> } > >> > >> we get: > >> > >> 0x0000002a: DW_TAG_namespace > >> DW_AT_name [DW_FORM_strp] ("foo") > >> > >> ... > >> > >> 0x00000050: DW_TAG_imported_declaration > >> DW_AT_decl_file [DW_FORM_data1] > ("/home/simark/build/binutils-gdb/gdb/test.cpp") > >> DW_AT_decl_line [DW_FORM_data1] (6) > >> DW_AT_import [DW_FORM_ref4] (0x0000002a) > >> DW_AT_name [DW_FORM_strp] ("bar") > >> > >> > >> And GDB is able to use bar: > >> > >> (gdb) p bar::x > >> $1 = 11 > >> > >> If DW_TAG_imported_declaration is ever used to describe variable > >> aliasing, then I don't see why that couldn't be supported in GDB, it > >> would just be a matter of implementing it (which may or may not be > >> difficult). > >> > >> Simon >