Re: [cdt-debug-dev] gdbPicl can't handle the main executable linked at 0

[chanskw@xxxxxxxxxx]

Linda,

I looked at your proposal about moving the "info file" call after running
to main
in order to get current start and end addresses for the main module.   The
"info file" call is made
by getMainModule function in an attempt to create a main module for the
debug session.  There are a few
reasons why getting the main module must happen before running to main and
I don't think
moving it after running to main is a safe to do.

One reason why we can't do it is due to the creation of a dummy part.
The dummy part is created for files whose source code cannot be located
and whose disassembly code cannot be generated properly.  It is for error
handling during calll stack report.
The dummy part is assumed to have a moduleID=1 and partID=1.  Since the
dummy part can only be created after
a main module is created.  Moving the creation of this main module after
running to main forces us
to move the dummy part creation after running to main as well.   As a
result, it will break
the assumption about its moduleID and partID and will break call stack info
reporting.

Breakpoints set from previous debug session will be restored in future
debug sessions.  UI keeps track
of a list of breakpoints that need to be restored and will send a
CmdBreakpointLocation command
after prepareProgram and before runToMain.  Each of the breakpoints set by
gdbPicl is associated with
a part.  In order for this association to work, a main module must exist
before trying to retore those breakpoints.

As you can see, we cannot casually move the "info file" call after
runToMain.
In order to obtain the addresses for the main module properly, I suggest
that we continue getting
the main module before run to main in prepareProgram.  However, we need
implement a new function that will call
"info file" and update main module's addresses as required.  This function
should be called after running to main.

Let me know if you have any comments or question about this.

Regards,
Samantha Chan