From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24588 invoked by alias); 30 Aug 2012 17:31:11 -0000 Received: (qmail 24570 invoked by uid 22791); 30 Aug 2012 17:31:11 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Aug 2012 17:30:58 +0000 From: "yufeng.zhang at arm dot com" To: gdb-prs@sourceware.org Subject: [Bug testsuite/14531] New: gdb.base/dprintf.exp fails in newlib environment Date: Thu, 30 Aug 2012 17:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: yufeng.zhang at arm dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q3/txt/msg00309.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14531 Bug #: 14531 Summary: gdb.base/dprintf.exp fails in newlib environment Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned@sourceware.org ReportedBy: yufeng.zhang@arm.com Classification: Unclassified I have seen the following failures in a bare-metal environment with newlib: set dprintf-function fprintf^M (gdb) PASS: gdb.base/dprintf.exp: Set dprintf function set dprintf-channel stderr^M (gdb) PASS: gdb.base/dprintf.exp: Set dprintf channel jump *start^M Line 0 is not in `foo'. Jump anyway? (y or n) y^M Continuing at 0x400178.^M ^M Breakpoint 2, main (argc=1, argv=0x2041bfe0) at gdb/testsuite/gdb.base/dprintf.c:33^M 33 int loc = 1234;^M (gdb) continue^M Continuing.^M kickoff 1234^M also to stderr 1234^M No symbol "stderr" in current context.^M (gdb) FAIL: gdb.base/dprintf.exp: 1st dprintf, fprintf continue^M Continuing.^M No symbol "stderr" in current context.^M (gdb) FAIL: gdb.base/dprintf.exp: 2nd dprintf, fprintf ---------------------- CUT ---------------------- The reason of the failure is because that 'stderr' in the newlib has the following definition: #ifndef _REENT_ONLY #define stdin (_REENT->_stdin) #define stdout (_REENT->_stdout) #define stderr (_REENT->_stderr) #else /* _REENT_ONLY */ #define stdin (_impure_ptr->_stdin) #define stdout (_impure_ptr->_stdout) #define stderr (_impure_ptr->_stderr) #endif /* _REENT_ONLY */ while in the GNU/Linux env, there are 'stderr's defined as both the macro and variable: /* Standard streams. */ extern struct _IO_FILE *stdin; /* Standard input stream. */ extern struct _IO_FILE *stdout; /* Standard output stream. */ extern struct _IO_FILE *stderr; /* Standard error output stream. */ #ifdef __STDC__ /* C89/C99 say they're macros. Make them happy. */ #define stdin stdin #define stdout stdout #define stderr stderr #endif This is probably why this test doesn't fail in GNU/Linux but newlib. I think we need a more robust way to test 'dprintf' with 'set dprintf-function fprintf' and 'set dprintf-channel stderr'. The C standard has specified that 'stderr' is just a macro. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.