From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 820 invoked by alias); 29 Sep 2009 15:44:08 -0000 Received: (qmail 792 invoked by uid 22791); 29 Sep 2009 15:44:04 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 15:43:59 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8TFhYdD031021; Tue, 29 Sep 2009 11:43:34 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8TFhVs7026533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 11:43:33 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n8TFhUlq019010; Tue, 29 Sep 2009 17:43:30 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id n8TFhShQ019009; Tue, 29 Sep 2009 17:43:28 +0200 Date: Tue, 29 Sep 2009 15:44:00 -0000 From: Jan Kratochvil To: Ulrich Weigand Cc: Matt Rice , Joel Brobecker , gdb-patches@sourceware.org Subject: [ia64] Regression: Re: [rfc] Fix Obj-C method calls on 64-bit PowerPC Message-ID: <20090929154328.GA15183@host0.dyn.jankratochvil.net> References: <8ba6bed40909281541y1d9455fas873a602caf2508fa@mail.gmail.com> <200909290050.n8T0o1dF004541@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909290050.n8T0o1dF004541@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00918.txt.bz2 Hi Ulrich, 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 $ echo 'main(){}' | gcc -o 1 -x c -; ./gdb -q -nx -ex 'b main' -ex q ./1 Cannot access memory at address 0x6000000000000c10 #0 ia64_convert_from_func_ptr_addr (gdbarch=0x6000000000167b20, addr=6917529027641085184, targ=0x600000000006fa40) at ia64-tdep.c:3511 #1 0x40000000003ca9d0 in gdbarch_convert_from_func_ptr_addr (gdbarch=0x6000000000167b20, addr=6917529027641085184, targ=0x600000000006fa40) at gdbarch.c:2559 #2 0x4000000000541a50 in find_methods (symtab=0x0, type=0 '\0', class=0x0, category=0x0, selector=0x60000fffffa79dc0 "main", syms=0x0, nsym=0x60000fffffa79e70, ndebug=0x60000fffffa79e6c) at objc-lang.c:1183 #3 0x4000000000543210 in find_imps (symtab=0x0, block=0x0, method=0x60000fffffa7ab89 "main", syms=0x0, nsym=0x60000fffffa79f90, ndebug=0x60000fffffa79f8c) at objc-lang.c:1344 #4 0x4000000000340d20 in decode_objc (argptr=0x60000fffffa7a210, funfirstline=1, file_symtab=0x0, canonical=0x60000fffffa7a2c0, saved_arg=0x60000fffffa7ab89 "main") at linespec.c:1131 #5 0x400000000033ea00 in decode_line_1 (argptr=0x60000fffffa7a210, funfirstline=1, default_symtab=0x0, default_line=0, canonical=0x60000fffffa7a2c0, not_found_ptr=0x60000fffffa7a300) at linespec.c:744 #6 0x4000000000262580 in parse_breakpoint_sals (address=0x60000fffffa7a210, sals=0x60000fffffa7a2a0, addr_string=0x60000fffffa7a2c0, not_found_ptr=0x60000fffffa7a300) at breakpoint.c:6092 #7 0x4000000000262af0 in do_captured_parse_breakpoint (ui=0x600000000016ff40, data=0x60000fffffa7a280) at breakpoint.c:6128 #8 0x40000000003949c0 in catch_exception (uiout=0x600000000016ff40, func=@0x4000000000a03d10: 0x4000000000262a10 , func_args=0x60000fffffa7a280, mask=6) at exceptions.c:462 #9 0x4000000000263600 in break_command_really (gdbarch=0x6000000000167b20, arg=0x60000fffffa7ab89 "main", cond_string=0x0, thread=0, parse_condition_and_thread=1, tempflag=0, hardwareflag=0, traceflag=0, ignore_count=0, pending_break_support=AUTO_BOOLEAN_AUTO, ops=0x0, from_tty=1, enabled=1) at breakpoint.c:6246 #10 0x40000000002645e0 in break_command_1 (arg=0x60000fffffa7ab89 "main", flag=0, from_tty=1) at breakpoint.c:6411 #11 0x4000000000264f60 in break_command (arg=0x60000fffffa7ab89 "main", from_tty=1) at breakpoint.c:6525 Attaching ia64 patch. 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 = 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 mst_data looks suspicious but on ppc64 case the function descriptor has really mst_data there: descriptor for `main': [20] .opd PROGBITS 00000000100108c8 0008c8 0000a8 00 WA 0 0 8 71: 0000000010010928 44 FUNC GLOBAL DEFAULT 20 main $40 = {ginfo = {name = 0x10bb4b50 "main", value = {ivalue = 268503336, block = 0x10010928, bytes = 0x10010928 "", address = 268503336, chain = 0x10010928}, language_specific = {cplus_specific = {demangled_name = 0x0}}, language = language_auto, section = 19, obj_section = 0x10bb46e8}, size = 44, filename = 0x10bb4990 "crtsavres.S", type = mst_data, target_flag_1 = 0, target_flag_2 = 0, hash_next = 0x0, demangled_hash_next = 0x0} code for `main': [10] .text PROGBITS 0000000010000320 000320 000368 00 AX 0 0 16 00000000100004c4 <.main>: $8 = {ginfo = {name = 0x10bb4c10 ".main", value = {ivalue = 268436676, block = 0x100004c4, bytes = 0x100004c4 "\220", address = 268436676, chain = 0x100004c4}, language_specific = {cplus_specific = {demangled_name = 0x0}}, language = language_auto, section = 9, obj_section = 0x10bb45f8}, size = 44, filename = 0x10bb4b80 "", type = mst_text, target_flag_1 = 0, target_flag_2 = 0, hash_next = 0x0, demangled_hash_next = 0x0} 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 So rather submitting first before possible next fixes. Regards, Jan gdb/ 2009-09-29 Jan Kratochvil * ia64-tdep.c (ia64_convert_from_func_ptr_addr): New variable buf. Check first the descriptor memory is readable. --- a/gdb/ia64-tdep.c +++ b/gdb/ia64-tdep.c @@ -3510,6 +3510,7 @@ ia64_convert_from_func_ptr_addr (struct gdbarch *gdbarch, CORE_ADDR addr, { enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); struct obj_section *s; + gdb_byte buf[8]; s = find_pc_section (addr); @@ -3520,10 +3521,12 @@ ia64_convert_from_func_ptr_addr (struct gdbarch *gdbarch, CORE_ADDR addr, /* Normally, functions live inside a section that is executable. So, if ADDR points to a non-executable section, then treat it as a function descriptor and return the target address iff - the target address itself points to a section that is executable. */ - if (s && (s->the_bfd_section->flags & SEC_CODE) == 0) + the target address itself points to a section that is executable. + Check first the memory of the whole length of 8 bytes is readable. */ + if (s && (s->the_bfd_section->flags & SEC_CODE) == 0 + && target_read_memory (addr, buf, 8) == 0) { - CORE_ADDR pc = read_memory_unsigned_integer (addr, 8, byte_order); + CORE_ADDR pc = extract_unsigned_integer (buf, 8, byte_order); struct obj_section *pc_section = find_pc_section (pc); if (pc_section && (pc_section->the_bfd_section->flags & SEC_CODE))