From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by sourceware.org (Postfix) with ESMTPS id 5C4943857801 for ; Sun, 27 Jun 2021 03:11:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C4943857801 Received: by mail-qt1-x834.google.com with SMTP id y9so1341074qtx.9 for ; Sat, 26 Jun 2021 20:11:05 -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:content-transfer-encoding; bh=UC/cmkrII5yBo8guTCSbG/3y/eQYk0ZCKNGhyMxkonQ=; b=a40r5MT/knQ0HsyPzD29gqwz6BIbn6np9Nv3LFR27Yzcj2h0E5YeRPXMAfd9ZcIWPx sspvqVgwM843HY/xKiUr23uvACcBdwffxw/iLPXk0hujTlYOAi4fas/L657KpWGZIUWg EorzTRGXDpPN5aNEEo8nk6Z2yb6V37o6fNQhJI3keFvoeTpCVvERkaSd9Sq7zq/VgSnh cVYGphREtHzfXx1eI3W15UKSAMlgCP48iTZZtfLR7a0oIWYXCqE0BJjWuvMDlYkwCQVe u3ZP7iJsIFG+jMOXLbttzkr+W/qHezunJyL9K57fNvJWQI98yy0pJ2fX1pvJZfDWf2zY Lw5g== X-Gm-Message-State: AOAM533zcs0Pnjd+VevIc1GNaRuoVb9MjNXe6sMsfIvqie1wOBFsMmkC otvThv0GBmxWip3dKLK/O8xv9P9FQIhsEfdUtRI= X-Google-Smtp-Source: ABdhPJxXFvLtxtmKo3Tjk86vwsoz3toa97lNbPkh7r2+fgcONDk/NUg9xbdLvmcKPq0NFdFcO9FK+Ax3ouM2Hs1+t+4= X-Received: by 2002:a05:622a:1046:: with SMTP id f6mr15758373qte.237.1624763464732; Sat, 26 Jun 2021 20:11:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: kamlesh kumar Date: Sun, 27 Jun 2021 08:40:27 +0530 Message-ID: Subject: Re: gdb unable to print alias variable To: David Blaikie Cc: Simon Marchi , gdb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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 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 03:11:08 -0000 David, I haven't updated the llvm review yet, but here is the diff I have used https://reviews.llvm.org/differential/diff/354719/ 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 names= pace: > > namespace ns { > > int i =3D 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/scra= tch/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 i= n the alias situation... > > Hmm, that seems to work correctly for me. Let me try Kamlesh's original p= atch... > > 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 vers= ion 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 thi= s thread. > > Kamlesh - which version of the patch are you testing that produced the DW= ARF 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 O= K 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 =3D 1; >> > extern int newname attribute((alias("oldname"))); >> > int main(){} >> > --------------------- >> > $clang test.c -g >> > $gdb a.out >> > (gdb) pt oldname >> > type =3D int >> > (gdb) pt newname >> > type =3D >> > (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 =3D 0x00000067, format =3D DWARF32, >> > version =3D 0x0004, abbr_offset =3D 0x0000, addr_size =3D 0x08 (next u= nit 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 appr= eciated. >> >> 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 =3D 11; >> }; >> >> namespace bar =3D 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 =3D 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