Re: ppc64 regression: [PATCH 1/2] Fix "list ambiguous_variable"

["Ulrich Weigand" <uweigand@de.ibm.com>]

Jan Kratochvil wrote:
> On Mon, 16 Oct 2017 17:03:18 +0200, Simon Marchi wrote:
> > The buildbot shows some failures on ppc64be:
> > 
> > PASS -> FAIL: gdb.base/dbx.exp: whereis my_list
> > PASS -> FAIL: gdb.mi/gdb669.exp: -thread-list-ids
> > PASS -> FAIL: gdb.mi/gdb669.exp: finding MI result string
> > PASS -> FAIL: gdb.mi/gdb669.exp: finding number of threads in MI output
> > 
> > I tested on gcc110, and bisect points to this patch here (for both tests).
> > A symptom of the problem is that "break main" generates two locations.
> > 
> > Before (at e5f25bc5^):
> > 
> > (gdb) b main
> > Breakpoint 1 at 0x10000560: file test.c, line 3.
> > (gdb) info breakpoints
> > Num     Type           Disp Enb Address            What
> > 1       breakpoint     keep y   0x0000000010000560 in main at test.c:3
> > 
> > After (at e5f25bc5)
> > 
> > (gdb) b main
> > Breakpoint 1 at 0x10000560: main. (2 locations)
> > (gdb) info breakpoints
> > Num     Type           Disp Enb Address            What
> > 1       breakpoint     keep y   <MULTIPLE>
> > 1.1                         y     0x0000000010000560 in main at test.c:3
> > 1.2                         y     0x0000000010020078 <main>
> 
> I have also hit this regression now on RHEL-7.5pre ppc64:
> 
> e5f25bc5d6dba5a5c4dd36e08afd57e918c63dea is the first bad commit
> commit e5f25bc5d6dba5a5c4dd36e08afd57e918c63dea
> Author: Pedro Alves <palves@redhat.com>
> Date:   Wed Sep 20 16:12:54 2017 +0100
>     Fix "list ambiguous_variable"
> 
> echo 'main(){}'|gcc -g -x c -;./gdb -batch ./a.out -ex start
> 	Temporary breakpoint 1 at 0x10000560: file <stdin>, line 1.
> 	Temporary breakpoint 1, main () at <stdin>:1
> 	1       <stdin>: No such file or directory.
> ->
> 	Temporary breakpoint 1 at 0x10000560: main. (2 locations)
> 	Program received signal SIGSEGV, Segmentation fault.
> 	0x7d82100810000554 in ?? ()

I now see this as well on Cell/B.E.  This is a serious regression that
causes "start" to always fail for me ...

The problem seems to be that GDB sets a breakpoint into the function
descriptor for main, which is not a good idea.

Looking at the commit identified above, it seems that GDB now only
runs the address through gdbarch_convert_from_func_ptr_addr if
msymbol_is_text returns true.  However, if the symbol points to
a function descriptor, msymbol_is_text would be false since this
is in fact outside the text section.

So I think probably we need to still run the address through
gdbarch_convert_from_func_ptr_addr, and if that detects that it
was indeed a function descriptor, always treat the resulting
address as a function.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com