Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble)

[Tak Auyeung]

Ted,

Thanks for looking over the changes. I was using caddress because the 
original functions ended with `address'. There is no reason why not to 
change it to func_address. I'll make the changes. And, you are right 
about the missed parse_and_eval_address, it should be changed to 
parse_and_eval_func_address as well.

I'll put in some more comments and send you another patch file (on top 
of my first patch). Alternatively, I can generate a patch file from scratch.

I can't sit down and do some coding until some time tonight. The patch 
will probably be available sometime tonight.

As to whether this change may break other platforms in gdb, I have to 
check how gdb differentiates a  pointer to a function returning void 
versus a pointer to void. This will probably take me a little longer...

The GDB folks should probably consider changing their 
parse_and_eval_address to parse_and_eval_data_address to be consistent 
with our (to be changed) parse_and_eval_func_address. In general, gdb 
needs to differentiate data address from func address if it is to 
support pure harvard architectures. This should, eventually, modify the 
protocol and use different commands for data and code memory.

Since apparently AVR is the only harvard architecture, I don't know if 
there is enough reasons to update gdb for native harvard support.

--Tak

Theodore A. Roth wrote:

> Hi Tak,
>
> I've been looking over your patch. It looks like you're on to something
> here. I just have a few questions. (line numbers refer to files after
> applying your patch)
>
> > From printcmd.c:
>   2342     {
>   2343       /* One argument.  */
>   2344       pc = parse_and_eval_address (arg);
>   2345       if (find_pc_partial_function (pc, &name, &low, &high) == 0)
>   2346         error ("No function contains specified address.\n");
>   2347 #if defined(TUI)
>
> Any reason why line 2344 shouldn't be using *_caddress too?
>
> What are the side effects of going from builtin_type_void_data_ptr to 
> builtin_type_void_func_ptr? Is it going to break gdb for other arches?
>
> I was a little confused by the *_caddress naming. Would it make more sense 
> to use parse_and_eval_func_address() and value_as_func_pointer()?
>
> We still might want to consult the gdb folks and see what they have to say 
> about the harvard arch and what should be done in this case. I'm just 
> worried that this change could affect other arches which would cause our 
> patch to be rejected when the submitted.
>
> If you can add a few comments describing why you added those functions in 
> eval.c and values.c, I'll merge it in with my patch since it does seem to 
> allow correct disassembly.
>
> Ted