regarding problem in porting gdb

regarding problem in porting gdb

[Shrirang Khishti]

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 

      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. 
	
	Is there any other way by which I can handle this situation in
GDB? 

Thanking you in advance
Regards
Shrirang Khisti
KPIT Cummins Infosystems Ltd.

Re: regarding problem in porting gdb

[Jim Blandy]

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.

Re: regarding problem in porting gdb

[Jim Blandy]

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

If your PC is only 16 bits long, and the upper bits are provided by
some other register, but the addresses GDB uses to access the target
address space index the larger address space, you may need to define a
gdbarch_read_pc method, and have your 'struct frame_unwind' include a
prev_pc function, to ensure that those upper bits get added as
appropriate.