From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18026 invoked by alias); 15 Jan 2014 17:13:27 -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 18014 invoked by uid 89); 15 Jan 2014 17:13:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout21.012.net.il Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Jan 2014 17:13:25 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MZG00200D28QU00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Wed, 15 Jan 2014 19:13:23 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZG002LPD6AQX00@a-mtaout21.012.net.il>; Wed, 15 Jan 2014 19:13:22 +0200 (IST) Date: Wed, 15 Jan 2014 17:13:00 -0000 From: Eli Zaretskii Subject: Re: [PUSHED] Fix go32-nat.c build fallout from to_detach constification. In-reply-to: <52D6B91C.2030402@redhat.com> To: Pedro Alves Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83d2jt418x.fsf@gnu.org> References: <52D6B91C.2030402@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00526.txt.bz2 > Date: Wed, 15 Jan 2014 16:36:44 +0000 > From: Pedro Alves > CC: Eli Zaretskii > > I pushed the patch below, approved by Eli offlist. Thanks. > FYI, djgpp still doesn't build OOTB: > > ../../src/binutils/readelf.c: In function 'print_symbol': > ../../src/binutils/readelf.c:474:4: error: implicit declaration of function 'mbrtowc' [-Werror=implicit-function-declaration] This is here: #ifdef HAVE_MBSTATE_T /* Try to find out how many bytes made up the character that was just printed. Advance the symbol pointer past the bytes that were displayed. */ n = mbrtowc (& w, symbol - 1, MB_CUR_MAX, & state); <<<<<<<<< #else n = 1; #endif The code (incorrectly) assumes that if the mbstate_t type is supported, so is mbrtowc. DJGPP has the former, but not the latter. I guess the solution is either to modify the HAVE_MBSTATE_T test or add a HAVE_MBRTOWC test. > cc1: all warnings being treated as errors > ... > ../../src/gdb/dwarf2read.c: In function 'open_and_init_dwp_file': > ../../src/gdb/dwarf2read.c:10550:7: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint32_t' [-Werror=format] > ../../src/gdb/dwarf2read.c:10550:7: error: format '%d' expects argument of type 'int', but argument 3 has type 'uint32_t' [-Werror=format] How does this compile on other platforms? I see this in dwarf2read.c: struct dwp_hash_table { uint32_t version, nr_columns; [...] struct dwp_file { /* Name of the file. */ const char *name; [...] /* Table of CUs in the file. */ const struct dwp_hash_table *cus; /* Table of TUs in the file. */ const struct dwp_hash_table *tus; And the line which is flagged by the compiler is this: /* The DWP file version is stored in the hash table. Oh well. */ if (dwp_file->cus->version != dwp_file->tus->version) { /* Technically speaking, we should try to limp along, but this is pretty bizarre. */ error (_("Dwarf Error: DWP file CU version %d doesn't match" <<<<<< " TU version %d [in DWP file %s]"), <<<<<<<<<<<<<<<<<<<<<< dwp_file->cus->version, dwp_file->tus->version, dwp_name); So it really tries to format uint32_t values with %d.