Re: [RFA 3/3] Windows-specific iterate_over_objfiles_in_search_order

[Joel Brobecker <brobecker at adacore dot com>]

> amd64-windows-tdep.c: In function ?$B!Famd64_windows_init_abi?$B!G:
> amd64-windows-tdep.c:178:15: error: ?$B!Fwindows_iterate_over_objfiles_in_search_order?$B!G undeclared (first use in this function)

Sorry, I thought I had compiled this file, but apparently not.

> But on Fedora 17 (all x86* archs) it regresses these new testcase, they should
> apparently be also made target specific:
> 
> -PASS: gdb.base/ctxobj.exp: print libctxobj2's this_version_num from partial symtab
> -PASS: gdb.base/ctxobj.exp: print libctxobj2's this_version_num from symtab
> +FAIL: gdb.base/ctxobj.exp: print libctxobj2's this_version_num from partial symtab

Yes, they should. I actually thought I had reverted them, since they
are not in my sandbox. Not sure what happened there, I will double-
check.

> I would also prefer to use there in all the definitions/declarations:
> typedef int 
>   (iterate_over_objfiles_in_search_order_cb_ftype) (struct objfile *objfile, 
>                                                     void *cb_data);

So do I, except that it raised a question: Where should this typedef
be located? It can't really be declared next to the only function
that's going to use it, since this section of the code is generated
on a loop from the data read in gdbarch.sh.  The only real location
I thought was acceptable would be at the start of gdbarch.h. It's
easy to modify gdbarch.sh to add this typedef, but then we create
a maintenance issue where, should we delete this gdbarch method, we
will probably forget to delete the typedef.  This is why I went with
the solution I chose. I'm OK going the other way, but I'd rather be
sure that this is what people want.

-- 
Joel