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

[Theodore A. Roth]

I'll play with this tomorrow. I want to fix the gdbserver interrupt stuff 
tonight.

In the mean time, keep digging in the gdb stuff and see if there's a way 
to do this completely in avr-tdep.c. I'll be doing the same tomorrow.

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
:)
:)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
:)>
:)
:)