Re: Problem in porting GDB

[Jim Blandy <jimb at red-bean dot com>]

On 12/23/05, Shrirang Khishti <shrirangk@kpitcummins.com> wrote:
> Hi
>
>         Thanks for your reply. I have made some changes in dwarf2read.c
> in "process_full_comp_unit" ,  and it is now working fine for single
> step, step  over etc for the memory model I discussed in previous mail.
> Also this is completely target dependant stuff, hopefully won't affect
> any other targets.

If you've made a change to dwarf2read.c, then the change is, by our
standards, not target-specific.

>         But what I  observed is that, suppose I put a breakpoint on main
> and then issue run command,  it is showing breakpoint  at _main()
> .Ideally it should show "break point at main()". Same thing happens if I
> put breakpoint on any other function. So though we are able to step run
> correctly through command line, but from insight it is going in
> disassembly. GDB is not showing any local variables saying that it is
> not in current context.

Did you read my other reply?

http://sourceware.org/ml/gdb/2005-12/msg00169.html

The addresses in the Dwarf info need to correspond to those used to
access memory in GDB.  If your Dwarf info is only carrying 16-bit code
addresses, but your address space is really indexed by 24-bit
addresses, and your code doesn't appear at the bottom of the address
space, you're going to have all sorts of problems.

If I understand the issue correctly, I don't think a change to
dwarf2read.c will be okay.