This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: regarding problem in porting gdb
- From: Jim Blandy <jimb at red-bean dot com>
- To: Shrirang Khishti <shrirangk at kpitcummins dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 21 Dec 2005 03:00:36 -0800
- Subject: Re: regarding problem in porting gdb
- References: <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.