From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 7026F3851C25 for ; Tue, 20 Oct 2020 15:04:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7026F3851C25 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E185A1E58E; Tue, 20 Oct 2020 11:04:38 -0400 (EDT) Subject: Re: [PATCH] gdb: add support for handling core dumps on arm-none-eabi To: Fredrik Hederstierna , Paul Mathieu Cc: "gdb-patches@sourceware.org" , Luis Machado , Alan Hayward References: <688f8081-e972-2ca1-255a-14b63e9e173d@simark.ca> From: Simon Marchi Message-ID: Date: Tue, 20 Oct 2020 11:04:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, URIBL_SBL, URIBL_SBL_A autolearn=no 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-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: , X-List-Received-Date: Tue, 20 Oct 2020 15:04:40 -0000 > Sorry my crappy corporate Outlook SMTP doesnt support me sending through git, and I had problems to using eg Google gmail, > I try to attach the patch here and in the meantime try to solve this in a better way, sorry for the inconvenience. Ok, thanks for trying. Is Outlook's SMTP not really SMTP? One warning to fix we get when applying: Applying: gdb: Support corefiles for arm-none-eabi .git/rebase-apply/patch:703: trailing whitespace. I'm leaving stylistic comments for later, it will be easier if you succeed using git-send-email. One thing that doesn't look right is this, in none_make_corefile_notes: int global_id = 1; struct thread_info *info = find_thread_global_id (global_id); As you might have noticed, GDB now supports being connected to multiple targets at the same time. So, inferior 1 could be a local GNU/Linux executable, while inferior 2 could be a remote bare-metal ARM program. So you can't assume that the thread you want to dump has global id 1. You should get the current inferior with the current_inferior function, and access its threads. Also, if GDB connects to a remote target that is able to report the OS's (FreeRTOS, for example) tasks as threads, is it possible to see them in GDB? If I understand correctly this section of the OpenOCD manual, OpenOCD can do it: http://openocd.org/doc/html/GDB-and-OpenOCD.html#RTOS-Support If so, I guess GDB should just dump all the current inferior's threads in the core dump. I see you have this commented out: /* make_cleanup (xfree, note_data); */ The way to do it now would be to make note_data a gdb::unique_xmalloc_ptr, and do "return note_data.release ();" when returning. This way, it gets automatically freed if something bad happens. And ideally, gdbarch_make_corefile_notes should be changed to return a gdb::unique_xmalloc_ptr, but that's out of the scope of this patch (I'll give it a quick try). You don't need an _initialize_none_tdep if you don't do anything in it. One last question: I see that you deal with AUXV stuff. Will bare-metal arm programs really have an auxiliary vector? Simon