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))
next prev parent 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