From: David Lecomber <david@lecomber.net>
To: gdb <gdb@sources.redhat.com>, patches <gdb-patches@sources.redhat.com>
Subject: Re: Fix powerpc64-linux inferior function calls
Date: Sun, 05 Mar 2006 11:59:00 -0000 [thread overview]
Message-ID: <1141559923.3098.51.camel@localhost.localdomain> (raw)
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
This is not a request for patch approval.. more for assistance in
getting the right patch given what this tells us..
The problem, is evaluating malloc in the target of a gcc -m64 compiled
binary..
"p (((void* (*) (int)) &malloc) (sizeof(int)))"
will cause a segfault in the inferior (certainly if malloc is not used
by the target).
I have discovered.. that the problem is when reading using
get_target_memory_unsigned inside
ppc64_linux_convert_from_func_ptr_addr. This goes down to target_read,
which doesn't go through the whole checking down the stack of targets
for a better reader., so when presented with current_target, it goes for
default_xfer_partial - which, for some reason related to
deprecated_xfer_partial, means it never goes to linux_nat_xfer_partial..
Moving to target_memory_read instead of get_target_memory inside
get_target_memory_unsigned is a non-winner --- because this is used with
a "temporary bfd" target to set a breakpoint whilst things are starting
(I think..). So, any attempt to moving to using proper memory reading
hierarchy is doomed by that.
So, my attached patch, checks to see whether the target provided to
ppc64_linux_convert_from_func_ptr_addr is the current target (not the
bfd temp one). If it is, then it goes and uses the "nice" memory
readers. Otherwise it falls back to the old..
It's a classic fixing the symptom, not the cause.. I'd prefer to fix
the cause (hence I'm not suggesting including this, unless anyone really
wants me to).
d.
--
David Lecomber <david@lecomber.net>
[-- Attachment #2: target-read.patch --]
[-- Type: text/x-patch, Size: 1544 bytes --]
*** /home/mark/skyride.sw/gdb-6.3.50.20051116/gdb/ppc-linux-tdep.c 2005-07-13 17:29:04.000000000 +0100
--- gdb/ppc-linux-tdep.c 2006-03-05 11:39:13.012233208 +0000
***************
*** 38,43 ****
--- 38,44 ----
#include "trad-frame.h"
#include "frame-unwind.h"
#include "tramp-frame.h"
+ #include "gdb_assert.h"
/* The following instructions are used in the signal trampoline code
on GNU/Linux PPC. The kernel used to use magic syscalls 0x6666 and
*************** ppc64_linux_convert_from_func_ptr_addr (
*** 794,805 ****
CORE_ADDR addr,
struct target_ops *targ)
{
struct section_table *s = target_section_by_addr (targ, addr);
/* Check if ADDR points to a function descriptor. */
if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
! return get_target_memory_unsigned (targ, addr, 8);
!
return addr;
}
--- 795,816 ----
CORE_ADDR addr,
struct target_ops *targ)
{
+ char buf[sizeof (ULONGEST)];
struct section_table *s = target_section_by_addr (targ, addr);
+
/* Check if ADDR points to a function descriptor. */
if (s && strcmp (s->the_bfd_section->name, ".opd") == 0)
! {
! if (targ != ¤t_target)
! return get_target_memory_unsigned (targ, addr, 8);
! else
! {
! gdb_assert (8 <= sizeof (buf));
! target_read_memory(addr, buf, 8);
! return extract_unsigned_integer (buf, 8);
! }
! }
return addr;
}
reply other threads:[~2006-03-05 11:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1141559923.3098.51.camel@localhost.localdomain \
--to=david@lecomber.net \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb@sources.redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).