public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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 != &current_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).