
I've been playing with a board file that forces every testcase to include a header file that does something like: #define main __gdb_testcase_main and then links an actual main() function that does some initialization and then jumps to __gdb_testcase_main. That runs into a number of testcases relying on main not having an explicit return statement, like e.g.,: gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/catch-follow-exec.c:27:1: warning: non-void function does not return a value [-Wreturn-type] gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/catch-signal.c:47:1: warning: non-void function does not return a value [-Wreturn-type] We don't get those warnings without my board because it is valid to not explicitly return from main. There's an implicit "return 0;". Since it doesn't hurt to be explicit, I've went ahead and added the explicit return statements. Also, a couple testcases either don't explicitly specify main's return type, or return void. Those are tweaked to explicitly return int. gdb/testsuite/ChangeLog: * gdb.base/catch-follow-exec.c (main): Add explicit return statement. * gdb.base/catch-signal.c (main): Likewise. * gdb.base/condbreak-call-false.c (main): Likewise. * gdb.base/consecutive.c (main): Add explicit return statement and return type. * gdb.base/cursal.c (main): Add explicit return statement. * gdb.base/cvexpr.c (main): Likewise. * gdb.base/display.c (main): Add explicit return statement and return type. * gdb.base/dprintf-detach.c (main): Add explicit return statement. * gdb.base/endianity.c (main): Likewise. * gdb.base/execd-prog.c (main): Likewise. * gdb.base/gdb1090.c (main): Likewise. * gdb.base/info_qt.c (main): Likewise. * gdb.base/lineinc.c (main): Likewise. * gdb.base/load-command.c (main): Likewise. * gdb.base/macscp1.c (main): Likewise. * gdb.base/pr10179-a.c (main): Likewise. * gdb.base/quit-live.c (main): Likewise. * gdb.base/scope0.c (main): Likewise. * gdb.base/settings.c (main): Likewise. * gdb.base/stack-checking.c (main): Return int. * gdb.base/varargs.c (main): Add explicit return statement. * gdb.cp/ambiguous.cc (main): Likewise. * gdb.cp/anon-struct.cc (main): Likewise. * gdb.cp/anon-union.cc (main): Likewise. * gdb.cp/bool.cc (main): Likewise. * gdb.cp/bs15503.cc (main): Likewise. * gdb.cp/cplusfuncs.cc (main): Likewise. * gdb.cp/cttiadd.cc (main): Likewise. * gdb.cp/extern-c.cc (main): Likewise. * gdb.cp/filename.cc (main): Likewise. * gdb.cp/formatted-ref.cc (main): Likewise. * gdb.cp/mb-ctor.cc (main): Likewise. * gdb.cp/member-ptr.cc (main): Likewise. * gdb.cp/minsym-fallback-main.cc (main): Likewise. * gdb.cp/overload-const.cc (main): Likewise. * gdb.cp/paren-type.cc (main): Likewise. * gdb.cp/parse-lang.cc (main): Likewise. * gdb.cp/pr-1023.cc (main): Likewise. * gdb.cp/psmang1.cc (main): Likewise. * gdb.cp/readnow-language.cc (main): Likewise. * gdb.cp/ref-params.cc (main): Likewise. * gdb.cp/rvalue-ref-params.cc (main): Likewise. * gdb.cp/virtbase2.cc (main): Likewise. * gdb.dwarf2/dw2-abs-hi-pc.c (main): Likewise. * gdb.dwarf2/dw2-namespaceless-anonymous.c (main): Likewise. * gdb.dwarf2/dw4-toplevel-types.cc (main): Likewise. * gdb.mi/mi-console.c (main): Likewise. * gdb.mi/mi-read-memory.c (main): Likewise. * gdb.modula2/multidim.c (main): Likewise. * gdb.opt/inline-small-func.c (main): Likewise. * gdb.python/py-rbreak.c (main): Likewise. * gdb.stabs/exclfwd1.c (main): Likewise. * gdb.trace/qtro.c (main): Likewise.
31 lines
1.3 KiB
C
31 lines
1.3 KiB
C
/* The following is written to tickle a specific bug in the macro
|
|
table code (now hopefully fixed), which doesn't insert new included
|
|
files in the #including file's list in the proper place. They
|
|
should be sorted by the number of the line which #included them, in
|
|
increasing order, but the sense of the comparison was reversed, so
|
|
the list ends up being built backwards. This isn't a problem by
|
|
itself, but the code to pick new, non-conflicting line numbers for
|
|
headers alleged to be #included at the same line as some other
|
|
header assumes that the list's line numbers are in ascending order.
|
|
|
|
So, given the following input, lineinc1.h gets added to lineinc.c's
|
|
#inclusion list first, at line 10. When the debug info reader
|
|
tries to add lineinc2.h at line 10 as well, the code will notice the
|
|
duplication --- since there's only one extant element in the list,
|
|
it'll find it --- and insert it after lineinc1.h, with line 11.
|
|
Since the code is putting the list in order of descending
|
|
#inclusion line number, the list is now out of order. When we try
|
|
to #include lineinc3.h at line 11, we won't notice the duplication. */
|
|
|
|
#line 10
|
|
#include "lineinc1.h"
|
|
#line 10
|
|
#include "lineinc2.h"
|
|
#line 11
|
|
#include "lineinc3.h"
|
|
|
|
int
|
|
main (int argc, char **argv)
|
|
{
|
|
return 0;
|
|
}
|