From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aPguFg5nfF9DIgAAWB0awg (envelope-from ) for ; Tue, 06 Oct 2020 08:46:06 -0400 Received: by simark.ca (Postfix, from userid 112) id 58C381EE0F; Tue, 6 Oct 2020 08:46:06 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A61151E58E for ; Tue, 6 Oct 2020 08:46:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4E47C3857013; Tue, 6 Oct 2020 12:46:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E47C3857013 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1601988362; bh=r+0SPeyj4Q9glCI48c91uBaatZVmOrGA1oV3qUgfxrU=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=EzxWwF43R5M3CEiSFs9AxdpAjtXdm/ecZv47aBrFyAlczBgWbHWGZ5IW+KXIgU1di mgt3ivxweJCSOaEkvur8bwxNH/fMDQm6gHJfLkUZ7Jxkt43x0khRcKkn8djFwEit1N 0S//UuZxu6Ua0/g2NJNSzP2QCLn01wY9VEYgwXlI= Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) by sourceware.org (Postfix) with ESMTPS id 71B093857013 for ; Tue, 6 Oct 2020 12:45:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 71B093857013 Received: by mail-qt1-x842.google.com with SMTP id y11so12853797qtn.9 for ; Tue, 06 Oct 2020 05:45:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=r+0SPeyj4Q9glCI48c91uBaatZVmOrGA1oV3qUgfxrU=; b=dROlplCt0Inui7DoT1KbMggQUQJrGR48nSBLk8P+KfXWMrlNUPyZjMgMPHa8KdM9aK +6ZH59K9HWLHI3Nat1naf6C8qNEa/fAuV1aYEEUbzFO+YPNppiFm94kqm9JKeuUL+lm3 mwrZIMo1VF2mkz5r5Drgxb0FPOMkB8CLQaiLB0zMDxxZW3d7NG8uGM+A0/9g46Dw2oSO 3Vq66klugwjvFCgPBEVAQ83a7ooHMkxjY9EMjJraySWemQSseqAVjMn9Mcy0AU2V2sb4 VzGSyrY9R3yQ+VHBsF9N8GJMDD5MhhGLIDuJaFIa2Wgrx3ELKa8sVYikBs1ozUnGoz/r MSTQ== X-Gm-Message-State: AOAM530QK7F1bI5Np3rdqYXmlTkK9c/Jp0H/MEz2Zin8NtRgOKhYJxif +p2vJXt6rriEnJXNeD1DF+k4KR+xWP2ZHw== X-Google-Smtp-Source: ABdhPJwLrg/TzkaX1R6JrGjxh88GDBGezFq6xrTA6TvUBfiym0evh9dDBKCC/n2+5STP/913oEYCFg== X-Received: by 2002:ac8:4a93:: with SMTP id l19mr4905508qtq.163.1601988358320; Tue, 06 Oct 2020 05:45:58 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:fe4b:e9:5f2f:a518:3d5a? ([2804:7f0:8283:fe4b:e9:5f2f:a518:3d5a]) by smtp.gmail.com with ESMTPSA id f76sm2366435qke.19.2020.10.06.05.45.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 05:45:57 -0700 (PDT) Subject: Re: [PATCH v2] gdb: add support for handling core dumps on arm-none-eabi To: Paul Mathieu , Simon Marchi References: <20201003181451.GA2211174@google.com> Message-ID: Date: Tue, 6 Oct 2020 09:45:54 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 10/6/20 1:32 AM, Paul Mathieu via Gdb-patches wrote: >>> Having a sniffer for GDB_OSABI_NONE seems like the right way to do this. >>> >>> Since the format isn't specified (yet), I can still freely control it. I >>> imagine I could add some sort of OSABI marker in the core file to mark >>> it as an arm-none-eabi core.o >>> >>> My first guess was to set the EI_OSABI e_ident elf header field to >>> ELFOSABI_NONE, but that happens to be the same enum value as >>> ELFOSABI_SYSV, which is afaik broadly used by the linux kernel for core >>> files. So it wouldn't be a good marker. >>> >>> Not sure what a better way would be to not abuse the ELF structure and >>> produce reasonable ELF core dumps (since they already work so well with >>> gdb). >> >> I really don't know either. Technically, it could be as simple as >> adding a new section / note of your choice, but I don't know if that >> would be an acceptable thing to do. > > So, I implemented a basic sniffer, and it seems like the core file is > being recognized as GDB_OSABI_NONE, but gdb crashes while loading it. > The assert & stack trace are as follows: > > gdbarch.c:3684: internal-error: void > gdbarch_iterate_over_regset_sections(gdbarch*, void (*)(const char*, > int, int, const regset*, const char*, void*), void*, const regcache*): > Assertion `gdbarch->iterate_over_regset_sections != NULL' failed. > > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x00007fd93a9a4537 in __GI_abort () at abort.c:79 > #2 0x000055e524ab29b7 in dump_core () at utils.c:204 > #3 0x000055e524ab770d in internal_vproblem(internal_problem *, const > char *, int, const char *, typedef __va_list_tag __va_list_tag *) ( > problem=0x55e524f5a3a0 , file= out>, line=, fmt=, ap=) > at utils.c:414 > #4 0x000055e524ab78eb in internal_verror (file=, > line=, fmt=, ap=ap@entry=0x7fffb8c40628) > at utils.c:439 > #5 0x000055e524be45c2 in internal_error > (file=file@entry=0x55e524c7e484 "gdbarch.c", line=line@entry=3684, > fmt=) > at errors.cc:55 > #6 0x000055e5248d8c48 in gdbarch_iterate_over_regset_sections > (gdbarch=0x55e5261014f0, > cb=0x55e5248354e0 regset const*, char const*, void*)>, cb_data=0x7fffb8c40730, > regcache=0x0) at gdbarch.c:3687 > #7 0x000055e524834f07 in core_target::fetch_registers > (regno=, regcache=0x55e5261625c0, this=) > at corelow.c:735 > #8 core_target::fetch_registers (this=, > regcache=0x55e5261625c0, regno=) at corelow.c:723 > #9 0x000055e524a6ee8d in target_fetch_registers > (regcache=regcache@entry=0x55e5261625c0, regno=regno@entry=15) at > target.h:1334 > #10 0x000055e5249df14a in regcache::raw_update (regnum=15, > this=0x55e5261625c0) at regcache.c:583 > #11 regcache::raw_update (this=0x55e5261625c0, regnum=) > at regcache.c:572 > #12 0x000055e5249df1ea in readable_regcache::raw_read > (this=0x55e5261625c0, regnum=15, buf=0x7fffb8c407c0 "\001") at > regcache.c:597 > #13 0x000055e5249e4edf in readable_regcache::cooked_read long, void> (this=this@entry=0x55e5261625c0, regnum=15, > val=val@entry=0x7fffb8c40818) at regcache.c:769 > #14 0x000055e5249e1ce3 in regcache_cooked_read_unsigned > (val=0x7fffb8c40818, regnum=, regcache=0x55e5261625c0) > at regcache.c:790 > #15 regcache_read_pc (regcache=0x55e5261625c0) at regcache.c:1294 > #16 0x000055e524907e2e in post_create_inferior > (target=target@entry=0x55e52615b480, from_tty=from_tty@entry=1) at > infcmd.c:303 > #17 0x000055e5248360ff in core_target_open (arg= variable: value has been optimized out>, > from_tty=) > at corelow.c:521 > #18 0x000055e5249571e0 in catch_command_errors (command= out>, arg=, from_tty=) at main.c:457 > #19 0x000055e524958ecf in captured_main_1 (context=) at > main.c:1167 > #20 0x000055e52495904b in captured_main (data=) at main.c:1268 > #21 gdb_main (args=) at main.c:1268 > #22 0x000055e524765f0c in main (argc=, argv= out>) at gdb.c:32 > > Seems to me like current_inferior()->gdbarch is returning the > arm-linux gdbarch. Maybe this is because the main .elf executable > itself is recognized as arm-linux? I have virtually no control over > the executable image, so I would not be able to insert the same kind > of note section as I would for a core file to differentiate it from > arm-linux executables. I think there may be enough hints here and there to be able to tell those apart via an heuristic. Isn't there a particular note section or flag that you can fetch and tell it is not a Linux executable but a bare-metal one? > > I'm not sure how to proceed forward, would you have any pointers? See the code in gdb/arm-tdep.c:arm_gdbarch_init, around the BFD flag checks and the ABI checks. Is that something usable? > > Thanks! > Paul >