From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) by sourceware.org (Postfix) with ESMTPS id 83943388A420 for ; Tue, 6 Oct 2020 04:33:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 83943388A420 Received: by mail-pj1-x1043.google.com with SMTP id j8so991689pjy.5 for ; Mon, 05 Oct 2020 21:33:03 -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=lDJzp/n4Bd56H6IBxa6wIPOaJngqAYo1jANyjW0fpdM=; b=Q0pSjP+2uHbFIK/PYsc9PJH6/2CJZCNbmmsP2z0/JND7kG6O5O/vF4U/UdZIGyRBdQ l+b3Qyv075LnNqLLA2OOU4pLJkw/Z8aRyZZI3k+X4G1+xCpFrRrGXPMCIgorEIuyRT7A 8YcHi3JUSWSh1/7Pa8TfMLmaT9K80+jXpVUisTaOPMrdDuiOmbgasSWaAVUbuPy8wndj AOyhHZnaVFKklXMA6kRBf4WlEAKKPBFuzY6QEfjc1WbmvelB1mCDX4qdg82C3idn70ai nby2ySRJE0Aa/cKohkYIZ8u/xv9J9Kp2UWY12mY1ZPEzmRA1KRAOmhr0sjBJePjV+sTk OSdA== X-Gm-Message-State: AOAM5338dTm2lZochjsJ1wTEaTn9L6+vN/xjtjrmf5pkT5UHpN3KxRzN UHaBOdT3scqxzAUQ5np10Z1IedZSh7fOm8cSqHlIlzmXlSr35A== X-Google-Smtp-Source: ABdhPJzUHtQeAL46EU9fkrCqzoCZzx/ArNd0OuETMpgGSNyGkiiv1F8ra8Y3YnwaNLEDBTAl7jx3Dj/VagvU0eRYl2U= X-Received: by 2002:a17:90a:1905:: with SMTP id 5mr2549906pjg.169.1601958782276; Mon, 05 Oct 2020 21:33:02 -0700 (PDT) MIME-Version: 1.0 References: <20201003181451.GA2211174@google.com> In-Reply-To: From: Paul Mathieu Date: Mon, 5 Oct 2020 21:32:51 -0700 Message-ID: Subject: Re: [PATCH v2] gdb: add support for handling core dumps on arm-none-eabi To: Simon Marchi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-18.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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-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, 06 Oct 2020 04:33:05 -0000 > > 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=, 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 , 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 (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=, from_tty=) at corelow.c:521 #18 0x000055e5249571e0 in catch_command_errors (command=, 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=) 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'm not sure how to proceed forward, would you have any pointers? Thanks! Paul