This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: regarding problem in porting gdb


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]