From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15191 invoked by alias); 29 Oct 2003 22:48:29 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15158 invoked from network); 29 Oct 2003 22:48:25 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 22:48:25 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9E6CB2B89; Wed, 29 Oct 2003 17:48:18 -0500 (EST) Message-ID: <3FA043B2.6090401@redhat.com> Date: Wed, 29 Oct 2003 22:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , "J. Johnston" Cc: Kevin Buettner , Marcel Moolenaar , ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: RFA: ia64 portion of libunwind patch References: <3F986E31.8050201@redhat.com> <1031024175718.ZM3475@localhost.localdomain> <3F996D88.9060505@redhat.com> <1031024185625.ZM9827@localhost.localdomain> <3F9F0180.2010702@redhat.com> <20031029012833.GA11070@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00851.txt.bz2 > Nothing which involves a syscall is acceptable in a tdep file. That's > what the t means - target support. ("tdep" mysteriously means "architecture vector support". That "t" really no longer makes sense :-() Yes, architecture vector shouldn't be directly making syscalls. Instead the architecture specific code should use the target vector to obtain this system information. Here I think the best option is to add another TARGET_OBJECT_xxxx variant and then use the target_read() method to pull in the data. As for the native target side, ia64-linux-nat should export something like ia64_linux_child_read_partial that performs the syscall. The tricky [er messy] part is wiring it into child_ops, I see there are lots of choices :-( - define a nm-*.c macro and have that enable the assignment (ex #define NATIVE_TO_READ_PARTIAL ia64_linux_child?) (ref KILL_INFERIOR) - have a callback set the to_read_partial method in child_ops (exec_set_find_memory_regions) - modify all the targets so that each implements the new method - others? Is this information available via /proc? In a core file? Andrew PS: Note this pending patch. Dependant on the timing you or I may need to tweak the name. http://sources.redhat.com/ml/gdb-patches/2003-10/msg00795.html