This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: 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: Fri, 23 Dec 2005 09:38:01 -0800
- Subject: Re: Problem in porting GDB
- References: <4A1BE23A7B777442B60F4B4916AE0F130959AD60@sohm.kpit.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.