This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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  <jan.kratochvil@redhat.com>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]