From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 4CBA73858012 for ; Tue, 30 Mar 2021 21:41:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4CBA73858012 Received: by mail-pf1-x429.google.com with SMTP id c17so13051118pfn.6 for ; Tue, 30 Mar 2021 14:41:33 -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=Ufn6C+CM5Ncf0R/hUmrunSnHKhL5n+g/ufzvNZwi5Xs=; b=cz1gJVMcKc+GvPEoRzcOHFay+7ULKHOk39zCXciR5tt5n042xfj4AnjWvmeUoVzjmi DhaAq7bJfK4ZyMQzBTZShIwPz/eQ4wD2laaquRkaBHlW5GtZT4ODIeJYPHMH+lCny1l1 wWjOy+nv6bog/6CZC0UAd6Sj6BgkOycNKqLeElNaSFHDkC3StSpehVUv+wZGsxu5n5oE LvPFUWH+SawvHx5KOz92UPP/2G+KYtdsPHvSIYunK0QF4Yyr4xuA+JXTTYbnGveYbvqf k+I65WhPMRzEVoq6Cmhe/XaQD7l6FCQVH+MSppTOLsdxwgGLZ55jgEKkOlySZdGXhfPs dkVg== X-Gm-Message-State: AOAM530VJBOQS31X31QUXMRyy206L3iNL2z+BVWONtRqdeolvg3GmZYR /p9tzHQ+CjMptJEamaFnJEN+dxfa+FwCg8vV+gY= X-Google-Smtp-Source: ABdhPJye2Vj1+Lc7uRmzGQqW+VFjdsXifn0uLuEtQtVopVwYwF0ZQa4WRwWlYlqxnZekzxjNLF/bto3x0aMsAJMo1sc= X-Received: by 2002:a63:43c2:: with SMTP id q185mr164262pga.41.1617140492412; Tue, 30 Mar 2021 14:41:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Blaikie Date: Tue, 30 Mar 2021 14:41:21 -0700 Message-ID: Subject: Re: Remote query for structure layout To: Simon Marchi Cc: Tim Newsome , gdb X-Spam-Status: No, score=-0.8 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: Tue, 30 Mar 2021 21:41:35 -0000 On Tue, Mar 30, 2021 at 2:33 PM Simon Marchi via Gdb wrote: > On 2021-03-30 4:35 p.m., Tim Newsome wrote: > > On Sun, Mar 28, 2021 at 5:00 AM wrote: > > > >> I would like to propose a new command for the remote protocol that can > be > >> used to > >> query structure layouts. > >> Essentially a `qSymbol` equivalent for the output of `ptype`. > >> > > > > I'm really interested in this. I've been working on OpenOCD FreeRTOS > > support and as Thomas points out, it's a fragile mess. > > > > There's another use case that this would be great for. FreeRTOS stores > > registers on the stack when it switches to another thread. OpenOCD needs > to > > know what this register layout is, and it also depends on compile time > > options. With this mechanism I think it would be possible for FreeRTOS to > > define a struct that represents how the registers are laid out on the > > stack. E.g.: > > struct register_stacking_t { > > uint32_t x1; > > uint32_t x2; > > uint32_t x3; > > uint32_t x4; > > ... > > uint32_t pc; > > }; > > > > Am I right that this will end up in the dwarf info even if the struct > > itself isn't used anywhere in the FreeRTOS code? This would simplify so > > much. > > It doesn't seem like it: > > $ cat test.cpp > struct foo > { > int a; > }; > > int main() { > > } > $ g++ test.cpp -g3 -O0 > $ llvm-dwarfdump -F -color a.out > a.out: file format elf64-x86-64 > > .debug_info contents: > 0x00000000: Compile Unit: length = 0x00000053, format = DWARF32, > version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at > 0x00000057) > > 0x0000000b: DW_TAG_compile_unit > DW_AT_producer [DW_FORM_strp] ("GNU C++14 10.2.0 > -mtune=generic -march=x86-64 -g3 -O0") > DW_AT_language [DW_FORM_data1] (DW_LANG_C_plus_plus) > DW_AT_name [DW_FORM_strp] ("test.cpp") > DW_AT_comp_dir [DW_FORM_strp] > ("/home/simark/build/lttng-ust/doc/examples/easy-ust") > DW_AT_low_pc [DW_FORM_addr] (0x0000000000001119) > DW_AT_high_pc [DW_FORM_data8] (0x000000000000000b) > DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000) > DW_AT_GNU_macros [DW_FORM_sec_offset] (0x00000000) > > 0x00000031: DW_TAG_base_type > DW_AT_byte_size [DW_FORM_data1] (0x04) > DW_AT_encoding [DW_FORM_data1] (DW_ATE_signed) > DW_AT_name [DW_FORM_string] ("int") > > 0x00000038: DW_TAG_subprogram > DW_AT_external [DW_FORM_flag_present] (true) > DW_AT_name [DW_FORM_strp] ("main") > DW_AT_decl_file [DW_FORM_data1] > ("/home/simark/build/lttng-ust/doc/examples/easy-ust/test.cpp") > DW_AT_decl_line [DW_FORM_data1] (6) > DW_AT_decl_column [DW_FORM_data1] (0x05) > DW_AT_type [DW_FORM_ref4] (0x00000031 "int") > DW_AT_low_pc [DW_FORM_addr] (0x0000000000001119) > DW_AT_high_pc [DW_FORM_data8] (0x000000000000000b) > DW_AT_frame_base [DW_FORM_exprloc] > (DW_OP_call_frame_cfa) > DW_AT_GNU_all_call_sites [DW_FORM_flag_present] (true) > > 0x00000056: NULL > > There might be some clever trick to force the compiler in emitting it > though, but I suppose it will always be a bit fragile, dependent on the > particular compiler. > Is the register layout in this struct part of the ABI? If so the debugger could assume it/hardcode the knowledge. If not, then it seems to me the right thing might be for the compiler to have builtin support for emitting this struct under a reserved name into every CU, perhaps? Not relying on source quirks to encourage it (as you say, would leave you at the whims of the compiler implementation), but actually make it explicitly part of compiler support for this architecture.