Re: Problem with "file" command from CVS_HEAD

[Steven Johnson <sjohnson at sakuraindustries dot com>]

Keith Seitz wrote:

> On Tue, 2005-05-17 at 00:04 -1100, Accounts wrote:
>
>  
>
> > I Believe this is the correct thing to do.
> >    
>
> Hmm. I'm not so sure... So what happens if you're not running and you
> type something like "tk gdb_loc main". Does it return something useful?
>
>  
Yes, i was re-considering this problem this morning.

> The problem is, of course, that there is no specific way to pass an
> error like this to the UI (the error is really an ignorable one in this
> case). We don't want invocations of gdb_loc to fail because we don't
> have a running target. I guess we could always pass some sort of fixed
> constant string (like "NOT_RUNNING" or something) instead of the PC
> value to indicate no registers or not running...
>  
The thought occured, that in the case of a non-running target, maybe the 
best reply to gdb_loc for a $PC is the value of the entry point for the 
program in question.  Its at least a sane default, and is not generating 
an error.

the code would then do something like the case where objc=2, but for the 
fixed address of entry point.

> I guess an easier way to see whether your patch works: Does the function
> browser work before you are running? Or you could simply type in the
> name of a file or function in the combo boxes in the tool bar.
>  
Well thats the killer, at the moment I am having problems with the 
function browser, and i dont know if its my patch or not.  The reason 
is, I cant test the function browser before i do the "file" command, 
because i have no functions to browse.  And when i do execute "file" i 
segfault, without my patch.  So its not possible for me to test it.

But i was thinking if i return the address of the entry_point as $pc in 
this case for gdb_loc that at least that might be a more sensible answer.

Now all i need to do to test it is work out how to get the address of 
the entry_point :)

another alternative is the address of "main" but an embedded program may 
not have a "main" as there is no real requirement in an embedded system 
to have a function with this name.

Also, it occured that i should include in the patch a patch of the 
Changelog.  Thats the correct protocol is it not.

Steven Johnson