From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id z1JZDL1wsGZRmTwAWB0awg (envelope-from ) for ; Mon, 05 Aug 2024 02:27:09 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=CoHiOWzz; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1DF131E0D0; Mon, 5 Aug 2024 02:27:09 -0400 (EDT) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id CE65B1E08C for ; Mon, 5 Aug 2024 02:27:06 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2C954385C6C7 for ; Mon, 5 Aug 2024 06:27:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C954385C6C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1722839226; bh=9bo02UXx6d2f7STmrgr3YcPCKVO+pcOr5leX0gywW1c=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=CoHiOWzzWITRGgQsdskvGBwL2TkKa0j8JJRx0suagmw/9npp2m2hmFG6IsbdCs1RH sQT5q7Y3N2F0Trjok/cHz0kSMvmUiDiQg0e6v2UI/54NmrefMyiR//CUh/+QK4/ZMc A18FpyuNDbus2fOCGSknuU0NG6lxvk3RcREy5fnA= Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by sourceware.org (Postfix) with ESMTPS id 9A474385841D for ; Mon, 5 Aug 2024 06:26:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A474385841D ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9A474385841D ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722839187; cv=none; b=ASNFsh0SDT32wP3iiEpG5I2IfJK8Kqmjy6Br/Pr/RK8CWtPojhykommceezVcTJWKbG+Kk1TP1ITFOiW7A9ui0UDrG2SCu6W1pqjUKvJmS4TbzT5LjLuMO2OMaXIwsB7J0i0nLWdb9+SEQggMREAJIsejZStAaAlC/WAR2KJWqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722839187; c=relaxed/simple; bh=1FC+Rjoc9wUUyslognUKnBSkI07df/XSIY0lhI9o6lk=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=jyWdHFxEDEEHqM1GBLESObVsedFDNuKAIuR5LOW+u+1+zrUMlB1UKvHCR1F+Xrf/ltkgAK/J+t+OLZKEDSzeJR/zCC3lFBgo8NsU+ixOvXh2XNP1XafcwuD7Rg16204OWljfBkeZAIH5DpM4CcTQKDtqJD6r/raY8h71uGFYnVA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a7a8e73b29cso829075266b.3 for ; Sun, 04 Aug 2024 23:26:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722839184; x=1723443984; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1FC+Rjoc9wUUyslognUKnBSkI07df/XSIY0lhI9o6lk=; b=qoMYKvjbwTUhcrrEDNAiJA4iSWSpsDjwINYmypmfgLbvub5W3spq0A9D41dvjqQ03N NL4+W1A6YH2XFRVgaiYErspgXpgbb8osbTCAQfmOUy61RddQbAPexw7RxEoo2urmuNgh z8Mmzk0MIkrLoznFiFdDCeQfZajVCizJ7j0+Iq/yJ/Y8PA59pecgGHa4SeAcBv5riV8K ickQtbsDHMZrANfabH5tzhBU0dD37jIPZ9tkpd1wRAcdTVIS7qNsY2J3UdrPAPkJIhqT w2McHzEDvUAF0oY6FTaaarGW/epKUzRg7Nl3SlgmaI4z69kvOXujWSLF9S7g9WGxBx5+ L5Ww== X-Gm-Message-State: AOJu0Yxu/5pO46gUGga6r5lVKZ3tEbhTQZbXHSAlbLwuAm1otaKLrulp YIRY+zZmyFt3ykr04pUnJRjg1QHT/7UVcqQI/EHx7dhkVXAhw7WmrvsaedWTyJW2D623r35Oz7y UQ6ZAAGx3G41sJ8Te1JzMNjq2UjsuRSCQ X-Google-Smtp-Source: AGHT+IFPPu+VFGRxkltNu/6wQNf4vIE2GXkj6mQDmmOVb4Nre0pa9s6ZtDwk4fCH/Zzzun/wn+bGAWgd4qR4ZQjBnP0= X-Received: by 2002:a17:907:3fa5:b0:a7a:387c:23f8 with SMTP id a640c23a62f3a-a7dc4dc06camr889546566b.3.1722839184053; Sun, 04 Aug 2024 23:26:24 -0700 (PDT) MIME-Version: 1.0 References: <66e2e4cb-03ce-4cb6-b0ca-6bf8c3af3f79@arm.com> In-Reply-To: <66e2e4cb-03ce-4cb6-b0ca-6bf8c3af3f79@arm.com> Date: Mon, 5 Aug 2024 08:26:13 +0200 Message-ID: Subject: Re: Porting GDB to an architecture with a shared memory model To: Luis Machado Cc: gdb@sourceware.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.30 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Max Larsson via Gdb Reply-To: Max Larsson Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hi Luis, Thanks for the hints, after testing various cases the objfile_relocate method is the one, which can perform the magic as long the symfile_object_file is given in the current_program_space. Because I found svr4_relocate_main_executable, which performs a solution with the mention exec_set_section_address if no symfile_object_file is present but a exec_bfd(). Now under which circumstances can a exec_bfd(9 be present but no symfile_object_file? kind regards Max On Mon, Jul 29, 2024 at 9:36=E2=80=AFAM Luis Machado = wrote: > On 7/28/24 18:33, Max Larsson via Gdb wrote: > > Hi everyone, > > > > I porting or better trying to report GDB to the AmigaOS 4 PPC target (e= lf > > based). > > I already succeeded in (re)porting the binutils stuff, but I'm stuck wi= th > > GDB. > > > > I have a working nat, which can create an inferior, set breakpoints,etc= .. > > but > > because the target has a shared memory model, the inferior is not > accessible > > at the vma addresses as specified in the elf format. Currently I'm tryi= ng > > to translate > > the vma addresses used by the gdb core to the physical address where th= e > > inferior > > ist loaded. > > > > I found in the source the method "set_gdbarch_has_shared_address_space" > and > > I think the gdbarch_has_shared_address_space gets used to tell gdb to > reuse the > address space rather than creating a new one, which is a step in the righ= t > direction. > > > "exec_set_action_address", with which I think I could tell the gdb core > > exec_set_section_address I suppose? That seems to get used in some places > still, > which is good. > > I think objfile_relocate is something that should be used here (maybe > indirectly through > some other means), maybe alongside some information about where in memory > things were > loaded for your case. But I can't see a way for you to directly influence > the way is works. > > > where the inferior > > is loaded, so that I don't need to translate the address, but until kno= w > I > > wasn't > > able to use them correctly. > > > > So can someone give me a hint how to realize that, or how gdb support > such > > a target, > > or not? > > I can tell gdb supports/used to support uclinux, but I'm not sure about t= he > state of such support currently. > > Maybe set_objfile_default_section_offset, which eventually calls > objfile_relocate > could provide hints on how you could change gdb's view of the memory > positioning. > > Also, check gdb/tic6x-linux-tdep.c and how it relocates things through a > solib > layer (gdb/solib-dsbt.c I think). For instance, > dsbt_relocate_main_executable. >