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

[Tak Auyeung]

Re: disassemble doesn't work because gdb grabs SRAM contents instead of 
flash contents

I have a solution to this problem now:

patch gdb/values.c:
clone the function value_as_pointer as value_as_cpointer, change 
builtin_type_void_data_ptr to builtin_type_void_func_ptr in the clone.

patch gdb/value.h:
clone the declaration of value_as_pointer as value_as_cpointer in value.h.
clone the declaration of parse_and_eval_address as 
parse_and_eval_caddress in value.h.

patch gdb/eval.c:
clone the function parse_and_eval_address as parse_and_eval_caddress, 
change value_as_pointer to value_as_cpointer in the clone.

patch gdb/printcmd.c:
change parse_and_eval_address to parse_and_eval_caddress in function 
disassemble_command

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

Tak Auyeung wrote:

> I have done some digging and found the problem was with 
> avr_pointer_to_address in gdb/avr-tdep.c. Currently, it only takes 
> TYPE_CODE_FUNC and TYPE_CODE_METHOD to translate to code space, 
> everything else gets translated to SRAM space.
>
> Turns out when gdb disassembles, the pointers to be translated to 
> addresses are of TYPE_CODE_VOID. A quick hack to add the acceptance of 
> TYPE_CODE_VOID as part of code space confirmed this.
>
> Now I'll check where gdb constructs the pointers for disassembly and 
> see if I can fix it there...
>
> --Tak