This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [aeb] Re: GNU toolchain and AEB
- To: Momchil Velikov <velco at fadata dot bg>
- Subject: Re: [aeb] Re: GNU toolchain and AEB
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Wed, 17 Jan 2001 16:33:07 -0500
- CC: gdb-patches at sources dot redhat dot com, Jim Ingham <jingham at apple dot com>
- Organization: Red Hat , Inc. - Toronto
- References: <3A65FE5A.C9D93781@cygnus.com> <874ryxq555.fsf@fadata.bg>
Momchil Velikov wrote:
>
> >>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
>
> >> The following looks also strange to me:
> >> 74 void TaskList::insert(Task * pTask)
> >> - 75 {
> >> - 76 Task * ppPrev = this->pTop;
> >> 77
> >> 78 //
> >> 79 // Handle the case of an empty list.
> >> 80 //
> >> - 81 if (ppPrev == NULL)
> >> 82 {
> >> 83 ppPrev == pTask;
> >> 84 return;
> >> 85 }
> >>
> >> This is how it looks in gdb. No instruction at "ppPrev == pTask; " and
> >> "return; ".
> >>
>
> Fernando> This is a very trivial method and it probably got optimized in some smart way.
> Fernando> Use the MIXED mode to see what are the assembler instructions that were
> Fernando> associated with the source lines.
>
> Sorry if I completely missed the point, but what instructions
> do you guys expect to be generated for `ppPrev == pTask;' ?
>
That is a question for the GCC list.
Here is how it works:
1) The compiler generates the code and also debugging information
(when you specify -g or similar option).
In this case the association between source line numbers and
instruction addresses.
2) All this extra info gets packed into the executable.
3) GDB reads WHATEVER THE COMPILER GENERATED.
So, unless GDB reads the information wrong (very unlikely as this code is
old and stable), the accuracy relies on the compiler side.
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9