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
>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
Fernando> 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;' ?
>>
Fernando> That is a question for the GCC list.
Since this is a comparison with no side effects
(I presume operator== is not overriden), I'd expect every decent
compiler to generate no code.
Fernando> Here is how it works:
Fernando> 1) The compiler generates the code and also debugging information
Fernando> (when you specify -g or similar option).
Fernando> In this case the association between source line numbers and
Fernando> instruction addresses.
Fernando> 2) All this extra info gets packed into the executable.
Fernando> 3) GDB reads WHATEVER THE COMPILER GENERATED.
Well, thanks, having implemented a debugger myself I
completely agree with you. :-)
Regards,
-velco