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

Ulrich Weigand
2017-11-26T16:38:05Z

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
>
> 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