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

[Theodore A. Roth]

If you have a fix, by alls means send me a diff agains my patch. I'll 
evaluate it and see if it's kosher. Just keep in mind that if we wish to 
get the patch submitted and accepted to the gdb folks, we'll want to be as 
inobtrusive as possible.

Take a look in the avr-tdep.c file and see if what you want to do can be 
done with the address_to_pointer and pointer_to_address functions.

Ted

On Tue, 1 Jan 2002, Tak Auyeung wrote:

:)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
:)
:)
:)
:)
:)_______________________________________________
:)Simulavr-devel mailing list
:)address@hidden
:)http://mail.freesoftware.fsf.org/mailman/listinfo/simulavr-devel
:)