Re: [2/2] RFA: implement 'set print symbol'

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 10 Apr 2012 09:48:21 +0200, Eli Zaretskii wrote:
> Why do we need to retain the old behavior?  You yourself said that no
> one will find this option to use it.

I have checked some (the first) FAIL cases of the testsuite and it does not
seem to be acceptable to be printed by default in its current form:

Breakpoint 7, marker3 (a=0x400918 <__dso_handle+48> "stack", b=0x400912 <__dso_handle+42> "trace") at ./gdb.base/break1.c:48^M
Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [15] .rodata           PROGBITS        00000000004008e0 0008e0 00003e 00   A  0   0  8
  [16] .eh_frame_hdr     PROGBITS        0000000000400920 000920 00006c 00   A  0   0  4
Symbol table '.symtab' contains 84 entries:
   Value          Size Type    Bind   Vis      Ndx Name
00000000004008e8     0 OBJECT  GLOBAL HIDDEN    15 __dso_handle
0000000000400920     0 SECTION LOCAL  DEFAULT   16 

__dso_handle is a false resolution.

So if it should be default there should be at least restriction to ignore
size-less objects.

The question is whether there should be also a possibility to resolve the
address even to size-less objects, something like (hypothetical):
	set print symbol no
	set print symbol sizeful-only (default)
	set print symbol always
but I think "set print symbol always" does not have to exist - there is always
the explicit "info symbol" command for special cases and the RFE PR/13907
should work fine with "set print symbol sizeful-only".

But even with size-ful objects the default on is not great:
(gdb) p t_structs_a(struct_val1)
$92 = <buf.2559>"foo"
Symbol table '.symtab' contains 177 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    43: 0000000000603a90     8 OBJECT  LOCAL  DEFAULT   25 buf.2559

Such local symbols just make no sense to display IMO.  Maybe there could be GDB
hack to suppress the \.\d+$ symbols from GCC?  Or even GCC suppressing them?

Too much information I thought may be the reason why some old-school hackers
may prefer the original behavior (I sure prefer the new behavior).  But I do
not mind if the option exists / does not exist there either way, it is up to
Tom.

There is still an open issue of updating the whole testsuite if the default is
changed.


Thanks,
Jan