This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: FYI: fix gdbserver PR 14917
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Fri, 07 Dec 2012 12:13:21 +0000
- Subject: Re: FYI: fix gdbserver PR 14917
- References: <877gowv98g.fsf@fleche.redhat.com> <20121207024350.GC31477@adacore.com>
On 12/07/2012 02:43 AM, Joel Brobecker wrote:
>> Index: server.h
> [...]
>> -CORE_ADDR current_insn_ptr;
>> -int emit_error;
>> +extern CORE_ADDR current_insn_ptr;
>> +extern int emit_error;
>
> Back in the good old days, I think the old code would have resulted
> in a link failure (symbol defined multiple times), right?
Depends on what compiler you've been using in the old days, I
suppose. :-) Backwards compatibility with the good old days is
the reason -fcommon is the default on most gcc targets, actually.
See e.g., the gcc manual:
-fno-common
In C code, controls the placement of uninitialized global variables. Unix C compilers have
traditionally permitted multiple definitions of such variables in different compilation units by
placing the variables in a common block. This is the behavior specified by -fcommon, and is
the default for GCC on most targets. On the other hand, this behavior is not required by ISO C, and on
some targets may carry a speed or code size penalty on variable references. The -fno-common
option specifies that the compiler should place uninitialized global variables in the data section of
the object file, rather than generating them as common blocks. This has the effect that if the same
variable is declared (without extern) in two different compilations, you get a multiple-definition error
when you link them. In this case, you must compile with -fcommon instead. Compiling with -fno-common is
useful on targets for which it provides better performance, or if you wish to verify that
the program will work on other systems that always treat uninitialized variable declarations this way.
--
Pedro Alves