This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: fix in features/Makefile
On Sun, Aug 24, 2008 at 06:02:40PM -0600, Tom Tromey wrote:
> 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
stdout isn't a tty... dubious we should be doing this if it is. I'm
not sure why you get tui here, though, I don't think I do. Do you
have the gdbtui binary installed as gdb?
> 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.
Makes sense, this makefile is already for manual use only and it's not
like they take a long time.
--
Daniel Jacobowitz
CodeSourcery