From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9220 invoked by alias); 15 May 2013 11:25:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9210 invoked by uid 89); 15 May 2013 11:25:40 -0000 X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 15 May 2013 11:25:39 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1UcZpx-0002BC-IW from Luis_Gustavo@mentor.com ; Wed, 15 May 2013 04:25:37 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 May 2013 04:25:37 -0700 Received: from [172.30.8.147] ([172.30.8.147]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 May 2013 04:25:36 -0700 Message-ID: <519370AE.50908@codesourcery.com> Date: Wed, 15 May 2013 11:25:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "'gdb-patches@sourceware.org'" , Mike Frysinger Subject: [RFC, gdbserver] Avoid defining linux_read_offsets when the target does not need it Content-Type: multipart/mixed; boundary="------------000604090007060807050701" X-Virus-Found: No X-SW-Source: 2013-05/txt/msg00516.txt.bz2 This is a multi-part message in MIME format. --------------000604090007060807050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1521 Hi, uClibc-based targets can load their programs in an offset in memory, and this information has historically been communicated to gdbserver via ptrace with the following options: PT_TEXT_ADDR, PT_DATA_ADDR and PT_TEXT_END_ADDR. We have a target that uses loadmaps as opposed to the above mechanism. It is just another ptrace request, but it doesn't use linux_read_offsets at all. linux_read_offsets is always defined (for uClibc-based targets) though, so gdbserver eventually calls it and it obviously returns an error. This error is propagated all the way to GDB, displaying an alarming and cryptic warning on the host's side. "warning: Remote failure reply: E01" Though the warning is harmless, the handling of this scenario could be improved a little. The following patch conditionally defines linux_read_offsets only for targets that are uClibc-based and that define PT_TEXT_ADDR, PT_DATA_ADDR and PT_TEXT_END_ADDR. Targets using other mechanisms won't define this function then, making gdbserver return an empty response to GDB (meaning packet not supported). GDB is happy again. Additionally, i see 3 different archs defining local constants. coldfire and c6x still seem to lack definitions in the kernel, but blackfin already has those. I've asked Mike Frysinger whether these can be removed. If so, i'll update the patch. Alternativelly, we could forward the burden of fetching offsets to the target backends, though the number of targets that would use this is quite limited. Luis --------------000604090007060807050701 Content-Type: text/x-patch; name="0001-qoffsets_uclinux.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-qoffsets_uclinux.diff" Content-length: 3672 2013-05-15 Luis Machado * linux-low.c: Move definition checks upwards for PT_TEXT_ADDR, PT_DATA_ADDR and PT_TEXT_END_ADDR. Update comments. (linux_read_offsets): Remove PT_TEXT_ADDR, PT_DATA_ADDR and PT_TEXT_END_ADDR guards. Update comments. (linux_target_op) stopped_data_address; } -#if defined(__UCLIBC__) && defined(HAS_NOMMU) -#if ! (defined(PT_TEXT_ADDR) \ - || defined(PT_DATA_ADDR) \ - || defined(PT_TEXT_END_ADDR)) -#if defined(__mcoldfire__) -/* These should really be defined in the kernel's ptrace.h header. */ -#define PT_TEXT_ADDR 49*4 -#define PT_DATA_ADDR 50*4 -#define PT_TEXT_END_ADDR 51*4 -#elif defined(BFIN) -#define PT_TEXT_ADDR 220 -#define PT_TEXT_END_ADDR 224 -#define PT_DATA_ADDR 228 -#elif defined(__TMS320C6X__) -#define PT_TEXT_ADDR (0x10000*4) -#define PT_DATA_ADDR (0x10004*4) -#define PT_TEXT_END_ADDR (0x10008*4) -#endif -#endif +#if defined(__UCLIBC__) && defined(HAS_NOMMU) \ + && defined(PT_TEXT_ADDR) && defined(PT_DATA_ADDR) \ + && defined(PT_TEXT_END_ADDR) + +/* This is only used for targets that define PT_TEXT_ADDR, + PT_DATA_ADDR and PT_TEXT_END_ADDR. If those are not defined, supposedly + the target has different ways of acquiring this information, like + loadmaps. */ /* Under uClinux, programs are loaded at non-zero offsets, which we need to tell gdb about. */ @@ -4859,7 +4872,6 @@ linux_stopped_data_address (void) static int linux_read_offsets (CORE_ADDR *text_p, CORE_ADDR *data_p) { -#if defined(PT_TEXT_ADDR) && defined(PT_DATA_ADDR) && defined(PT_TEXT_END_ADDR) unsigned long text, text_end, data; int pid = lwpid_of (get_thread_lwp (current_inferior)); @@ -4888,7 +4900,6 @@ linux_read_offsets (CORE_ADDR *text_p, C return 1; } -#endif return 0; } #endif @@ -5887,7 +5898,9 @@ static struct target_ops linux_target_op linux_remove_point, linux_stopped_by_watchpoint, linux_stopped_data_address, -#if defined(__UCLIBC__) && defined(HAS_NOMMU) +#if defined(__UCLIBC__) && defined(HAS_NOMMU) \ + && defined(PT_TEXT_ADDR) && defined(PT_DATA_ADDR) \ + && defined(PT_TEXT_END_ADDR) linux_read_offsets, #else NULL, --------------000604090007060807050701--