On Fri, May 25, 2012 at 1:50 AM, Pedro Alves <palves@redhat.com> wrote:
> On 05/25/2012 09:21 AM, Doug Evans wrote:
>
>>
>> The output is different from the previous code, I didn't take into
>> account the symbols that gdb creates for @plt entries.  I think if we
>> want to continue to provide the current output, we should add an
>> option to "info var|fun|type" to produce it: the normal case shouldn't
>> be that slow.
>
>
> Different how?  The patch has no testsuite updates, so the email reader is
> left wondering.  ;-)

In the "Non-debugging symbols" section of the output, when a symbol
would have been found in another objfile, the code would have not
printed the non-@plt form of the function name.
With this patch we have a decision to make.  Searching all the other
objfiles is not reasonable (IMO) so what to do?  I can think of two
possibilities: always print it or never print it.  Since the symbol in
question is an artificial symbol created by gdb I have opted for never
printing it.

Thus instead of seeing this in the "Non-debugging symbols" section of
the output:

0x1234 foo@plt
0x1234 foo

the output will contain:

0x1234 foo@plt

Here is v3 of the patch.  I added a testcase.
Regression tested on amd64-linux.

Ok to check in?

2012-05-27  Doug Evans  <dje@google.com>

        * symtab.c (minimal_symbol): New member created_by_gdb.
        * elfread.c (elf_symtab_read): Set created_by_gdb for @plt
minsym
        created by gdb.
        * symtab.c (lookup_msymbol_in_objfile): New function.
        (search_symbols): Call it.  Only scan minsyms if nfiles == 0.

        testsuite:
        * gdb.base/info-fun.exp: New file.
        * gdb.base/info-fun.c: New file.
        * gdb.base/info-fun-solib.c: New file.