Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Matt Rice <ratmice@gmail.com>,
	Joel Brobecker <brobecker@adacore.com>,
	        gdb-patches@sourceware.org
Subject: [ia64] Regression: Re: [rfc] Fix Obj-C method calls on 64-bit PowerPC
Date: Tue, 29 Sep 2009 15:44:00 -0000	[thread overview]
Message-ID: <20090929154328.GA15183@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <200909290050.n8T0o1dF004541@d12av02.megacenter.de.ibm.com>

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


  reply	other threads:[~2009-09-29 15:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-27 21:49 Ulrich Weigand
2009-09-28 17:51 ` Joel Brobecker
2009-09-28 22:41   ` Matt Rice
2009-09-29  0:50     ` Ulrich Weigand
2009-09-29 15:44       ` Jan Kratochvil [this message]
2009-09-29 16:07         ` [ia64] Regression: " Ulrich Weigand
2009-09-29 16:17           ` Jan Kratochvil
2009-09-29 16:16         ` Joel Brobecker
2009-09-29 16:30           ` Jan Kratochvil
2009-09-29 16:40             ` Joel Brobecker
2009-09-29 19:11               ` Jan Kratochvil
2009-09-29 16:45           ` Ulrich Weigand
2009-09-29 19:07             ` [commit] Avoid Obj-C test timeouts due to symbols not found Ulrich Weigand
2009-09-29 17:27         ` [rfc] Move PC in-range check in objc-lang.c:find_methods (Re: [ia64] Regression) Ulrich Weigand
2009-09-29 17:46           ` Joel Brobecker
2009-09-29 21:08         ` [ia64] Regression: Re: [rfc] Fix Obj-C method calls on 64-bit PowerPC Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090929154328.GA15183@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ratmice@gmail.com \
    --cc=uweigand@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox