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

[Theodore A. Roth]

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

On Tue, 1 Jan 2002, Tak Auyeung wrote:

:)Attached is a patch file for the suggested changes. Apply the patch when 
:)you are in the gdb subdirectory.
:)
:)--Tak
:)

<snip>

:)>
:)> The key is to cast code address as builtin_type_void_func_ptr instead 
:)> of builtin_type_void_data_ptr. This enables the pointer_to_address 
:)> function in avr_tdep.c to handle the SRAM flag properly.
:)>
:)> Ted, do you want to integrate this into your gdb patch? Since these 
:)> changes only affect disassembly, they should present very minimal (if 
:)> any!) impact to the rest of gdb functionality. Anyway, let me know if 
:)> this patch will be integrated, thanks!
:)>
:)> --Tak