Re: FYI: fix gdbserver PR 14917

[Pedro Alves <palves at redhat dot 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