Re: [ia64] Regression: Re: [rfc] Fix Obj-C method calls on 64-bit PowerPC

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Jan Kratochvil wrote:

> ia64 is now broken, also on the 7.0 branch due to the check-in:
>  http://sourceware.org/ml/gdb-cvs/2009-09/msg00210.html

Huh.  Sorry for the breakage ...

> Checked that in the ia64 case there is:
> 
> #4  0x40000000005419c0 in find_methods (symtab=0x0, type=0 '\0', class=0x0, category=0x0, selector=0x60000fffff829dc0 "main", syms=0x0, nsym=0x60000fffff829e70, ndebug=0x60000fffff829e6c) at objc-lang.c:1183
> 1183		  pc = gdbarch_convert_from_func_ptr_addr (gdbarch, pc,
> (gdb) p *msymbol
> $6 = {ginfo = {name = 0x6000000000191360 "__data_start", value = {ivalue = 6917529027641085184, block = 0x6000000000000d00, bytes = 0x6000000000000d00 <Address 0x6000000000000d00 out of bounds>, address = 6917529027641085184, chain = 0x6000000000000d00}, language_specific = {cplus_specific = {demangled_name = 0x0}}, language = language_auto, section = 20, obj_section = 0x6000000000190ec0}, size = 0, filename = 0x60000000001911c0 "../../gcc/config/ia64/crtend.asm", type = mst_data, target_flag_1 = 0, target_flag_2 = 0, hash_next = 0x0, demangled_hash_next = 0x0}
> -> value = 0x6000000000000d00
> which fails to be read as <0x6000000000000d04..0x6000000000000d08) is just missing:
> Section Headers:
>   [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
>   [21] .data             PROGBITS        6000000000000d00 000d00 000004 00  WA  0   0  4
>   [22] .ctors            PROGBITS        6000000000000d08 000d08 000010 00  WA  0   0  8

I agree that ia64_convert_from_func_ptr_addr should not error out in such cases,
so your patch looks good to me (would have looked good in any case, even without
the Obj-C changes) ...   Are you going to check it in?

> mst_data looks suspicious but on ppc64 case the function descriptor has really
> mst_data there:

OK, that's probably the core change that triggers the problem.  But as you say,
on ppc64 we do actually get mst_data minimal symbols for functions (that point
to the descriptor) ...

> On ia64-rhel5.4-linux-gnu with this patch there are still these regressions:
> +FAIL: gdb.base/corefile.exp: print func2::coremaker_local
> +FAIL: gdb.base/corefile.exp: backtrace in corefile.exp
> +FAIL: gdb.base/corefile.exp: up in corefile.exp
> +FAIL: gdb.base/corefile.exp: up in corefile.exp (reinit)
> +FAIL: gdb.base/gcore.exp: where in corefile (pattern 1)
> +FAIL: gdb.base/gcore.exp: corefile restored general registers
> +FAIL: gdb.base/gcore.exp: corefile restored all registers
> +FAIL: gdb.base/gcore.exp: capture_command_output failed on print array_func::local_array.
> +FAIL: gdb.base/gcore.exp: corefile restored stack array
> +FAIL: gdb.base/gcore.exp: corefile restored backtrace
> +FAIL: gdb.gdb/selftest.exp: unknown source line after step over ttyarg initialization
> +FAIL: gdb.gdb/selftest.exp: step into xmalloc call
> +FAIL: gdb.threads/gcore-thread.exp: corefile contains at least two threads
> +FAIL: gdb.threads/gcore-thread.exp: a corefile thread is executing thread2
> +FAIL: gdb.threads/gcore-thread.exp: thread2 is current thread in corefile

Are these regressions also introduced by my Obj-C patch?  That seems
really odd to me ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com