From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24042 invoked by alias); 25 Aug 2008 00:03:59 -0000 Received: (qmail 24032 invoked by uid 22791); 25 Aug 2008 00:03:58 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 25 Aug 2008 00:03:26 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m7P02n0o028162 for ; Sun, 24 Aug 2008 20:03:09 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m7P02baC005664 for ; Sun, 24 Aug 2008 20:02:38 -0400 Received: from opsy.redhat.com (vpn-10-23.bos.redhat.com [10.16.10.23]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m7P02W0U024698; Sun, 24 Aug 2008 20:02:32 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id B109E37831C; Sun, 24 Aug 2008 18:02:41 -0600 (MDT) To: gdb-patches@sourceware.org Subject: Re: RFA: fix in features/Makefile References: <20080824223751.GB7324@caradoc.them.org> From: Tom Tromey Reply-To: Tom Tromey X-Attribution: Tom Date: Mon, 25 Aug 2008 00:03:00 -0000 In-Reply-To: <20080824223751.GB7324@caradoc.them.org> (Daniel Jacobowitz's message of "Sun\, 24 Aug 2008 18\:37\:51 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2008-08/txt/msg00607.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Tom> This patch changes features/Makefile to use gdb's logging feature Tom> rather than redirection to create the output files. This fixed the Tom> problem I saw. Daniel> But why did it? If you can't redirect GDB's output, something's Daniel> wrong. Yeah, I should have looked first. I disabled stdout buffering and used frysk's ftrace to get a stack trace at the point where the weird stuff is written: #0 0x00110416 in __kernel_vsyscall() from [vdso] #1 0x05e4d135 in new_do_write() from libc-2.7.so #2 0x05e4d41f in _IO_do_write@@GLIBC_2.1() from libc-2.7.so #3 0x05e4dd28 in _IO_file_overflow@@GLIBC_2.1() from libc-2.7.so #4 0x05e50793 in __overflow() from libc-2.7.so #5 0x05e4a55b in putc() from libc-2.7.so #6 0x082f35c5 in _rl_output_character_function() from gdb #7 0x006c554a in tputs() from libtinfo.so.5.6 #8 0x082f3741 in _rl_enable_meta_key() from gdb #9 0x082df0d8 in readline_initialize_everything() from gdb #10 0x082def5c in rl_initialize() from gdb #11 0x081a6081 in tui_initialize_readline() from gdb #12 0x081a6ab7 in tui_init() from gdb #13 0x0820ba2b in interp_set() from gdb #14 0x080a1a1b in captured_main() from gdb #15 0x0820b6cc in catch_errors() from gdb #16 0x080a20f8 in gdb_main() from gdb #17 0x080a1027 in main() from gdb #18 0x05e00390 in __libc_start_main() from libc-2.7.so #19 0x080a0f21 in _start() from gdb So, it is readline. Maybe we could fool it by setting TERM=dumb or something. I suppose -batch ought to do this kind of thing automatically. I'll file a bug report soon. Tom> This patch also makes it so that the .c files are always rebuilt in Tom> response to a 'make'. Without the FORCE code, make was not running Tom> the rule for me. Daniel> If you're going to change the generating code, IMO it's reasonable to Daniel> remove and remake the generated files by hand... Note that due to the use of move-if-change, you only get updates if there really were any. This change just makes it simpler to ask for the changes. I don't really care either way though. Tom