Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@red-bean.com>
To: Shrirang Khishti <shrirangk@kpitcummins.com>
Cc: gdb@sources.redhat.com
Subject: Re: regarding problem in porting gdb
Date: Wed, 21 Dec 2005 11:00:00 -0000	[thread overview]
Message-ID: <8f2776cb0512210300y2d933c39gbf9a381404d7be05@mail.gmail.com> (raw)
In-Reply-To: <4A1BE23A7B777442B60F4B4916AE0F13094BF11E@sohm.kpit.com>

On 12/21/05, Shrirang Khishti <shrirangk@kpitcummins.com> wrote:
> Hi Jim
>         Thanks for your help and changes suggested by you. But in our
> target GCC we have added a different memory model which handles 32 bits
> of address size  and for that we are not getting any problem. But for
> the memory model  for which  I am  facing the problem we don't need 32
> bits address size(For this model code size is limited to 64K but
> situated at some far address). So in this case it is as good as debug
> info is showing virtual addresses related to program counter

Well, that's the source of your problem, though.  When GDB reads or
writes code in the target, it needs to use addresses from 0xc00000 --
0xc0ffff, is that correct?  Then those are the addresses that must
appear in the line number info, and in the low_pc/high_pc/range list
values in the .debug_info section.

The user can specify a relocation to be applied to debugging
information, via arguments to the 'add-symbol-file' command.  But
there isn't any way for a particular architecture to do that, as far
as I know.

>       Also regarding ADDRESS_TO_POINTER and POINTER_TO_ADDRESS hooks , I
> observed that these are not coming in the picture while setting the
> break point or single stepping.

No; they deal with the case where the relationship between pointers as
they are represented in the target program and the addresses GDB must
use to read and write target code and memory is non-trivial.  They
don't deal with incorrect addresses in the debug info.


  reply	other threads:[~2005-12-21 11:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 10:18 Shrirang Khishti
2005-12-21 11:00 ` Jim Blandy [this message]
2005-12-21 11:04 ` Jim Blandy

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=8f2776cb0512210300y2d933c39gbf9a381404d7be05@mail.gmail.com \
    --to=jimb@red-bean.com \
    --cc=gdb@sources.redhat.com \
    --cc=shrirangk@kpitcummins.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