Re: [PATCH v2 0/2] Initial support for FreeBSD/aarch64

[Pedro Alves <palves at redhat dot com>]

On 09/05/2017 03:51 AM, John Baldwin wrote:
> On 9/4/17 6:52 AM, Pedro Alves wrote:
>> On 08/16/2017 02:57 PM, John Baldwin wrote:
>>> This series adds initial support for FreeBSD/aarch64.  It does not
>>> yet include support for hardware breakpoints/watchpoints as that is
>>> not currently supported by FreeBSD's kernel.
>>>
>>> I realized yesterday that I had forgotton to 'git add' the
>>> aarch64-fbsd-nat.c file for the second patch, so this series adds
>>> the missing file.
>>
>> I skimmed this and it looks good to me.
>>
>> One tiny comment:
>>
>>  > +/* Provide a prototype to silence -Wmissing-prototypes.  */
>>  > +extern initialize_file_ftype _initialize_aarch64_fbsd_tdep;
>>
>> ...
>>
>>  > +/* Provide a prototype to silence -Wmissing-prototypes.  */
>>  > +void _initialize_aarch64_fbsd_nat (void);
>>
>> These prototypes no longer make sense in C++ [1], and we
>> could/should remove all the existing ones to avoid confusion.
> 
> I assumed it was more for the warning per the comment.

-Wmissing-prototypes doesn't exist in G++, only in 
GCC-the-C-compiler, so the comments about the warning
are all out of date now.

It doesn't exist in G++ because unlike in C, in C++ there's
no such thing as a declaration that is not a prototype.

Hmm, maybe we should consider adding -Wmissing-declarations, to
get back part of the old usefulness of -Wmissing-prototypes -- the
part about detecting when extern functions can be made static.

> I wonder if
> we shouldn't think about replacing init.c with something more C++y
> anyway?  We could perhaps do it incrementally by adding a global
> container of function pointers and a wrapper class whose constructor
> accepts a function pointer and adds it to the container.  Then we
> would do a for-each over the container at the same place as
> initialize_all_files().  If the ordering doesn't matter then this
> could be rolled out over time (i.e. adding the new container and
> wrapper class and then individual _init* functions could be converted
> to the new scheme).

Not sure.  OTOH, that seems like it'd add a little runtime/startup time
overhead for no real gain?  For most cases where the ordering truly doesn't
matter, we could make the wrapper classes's ctor call the function
directly, though I wonder whether that's a good direction to go if
we consider moving gdb in the direction of making it a dlopen-able library.

Thanks,
Pedro Alves