[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble)
From: |
Tak Auyeung |
Subject: |
Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble) |
Date: |
Tue, 01 Jan 2002 18:24:00 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 |
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
*** old_printcmd.c Tue Jan 1 16:56:07 2002
--- printcmd.c Tue Jan 1 17:55:07 2002
*************** disassemble_command (char *arg, int from
*** 2368,2375 ****
{
/* Two arguments. */
*space_index = '\0';
! low = parse_and_eval_address (arg);
! high = parse_and_eval_address (space_index + 1);
}
#if defined(TUI)
--- 2368,2375 ----
{
/* Two arguments. */
*space_index = '\0';
! low = parse_and_eval_caddress (arg);
! high = parse_and_eval_caddress (space_index + 1);
}
#if defined(TUI)
*** old_eval.c Tue Jan 1 16:44:18 2002
--- eval.c Tue Jan 1 16:45:24 2002
*************** parse_and_eval_address (char *exp)
*** 85,90 ****
--- 85,103 ----
return addr;
}
+ CORE_ADDR
+ parse_and_eval_caddress(char *exp)
+ {
+ struct expression *expr = parse_expression (exp);
+ register CORE_ADDR addr;
+ register struct cleanup *old_chain =
+ make_cleanup (free_current_contents, &expr);
+
+ addr = value_as_cpointer (evaluate_expression (expr));
+ do_cleanups (old_chain);
+ return addr;
+ }
+
/* Like parse_and_eval_address but takes a pointer to a char * variable
and advanced that variable across the characters parsed. */
*** old_values.c Tue Jan 1 16:45:30 2002
--- values.c Tue Jan 1 17:59:46 2002
*************** value_as_pointer (value_ptr val)
*** 603,608 ****
--- 603,622 ----
return unpack_long (VALUE_TYPE (val), VALUE_CONTENTS (val));
#endif
}
+
+ CORE_ADDR
+ value_as_cpointer (value_ptr val)
+ {
+ COERCE_ARRAY (val);
+ /* TA: force type to function */
+ if (TYPE_CODE (VALUE_TYPE (val)) == TYPE_CODE_INT
+ && (TYPE_LENGTH (VALUE_TYPE (val))
+ <= TYPE_LENGTH (builtin_type_void_func_ptr)))
+ {
+ val = value_cast (builtin_type_void_func_ptr, val);
+ }
+ return unpack_long (VALUE_TYPE (val), VALUE_CONTENTS (val));
+ }
/* Unpack raw data (copied from debugee, target byte order) at VALADDR
as a long, or as a double, assuming the raw data is described
*** old_value.h Tue Jan 1 16:54:59 2002
--- value.h Tue Jan 1 16:55:45 2002
*************** extern DOUBLEST value_as_double (value_p
*** 289,294 ****
--- 289,296 ----
extern CORE_ADDR value_as_pointer (value_ptr val);
+ extern CORE_ADDR value_as_cpointer (value_ptr val);
+
extern LONGEST unpack_long (struct type *type, char *valaddr);
extern DOUBLEST unpack_double (struct type *type, char *valaddr, int *invp);
*************** extern value_ptr parse_to_comma_and_eval
*** 434,439 ****
--- 436,443 ----
extern struct type *parse_and_eval_type (char *p, int length);
extern CORE_ADDR parse_and_eval_address (char *exp);
+
+ extern CORE_ADDR parse_and_eval_caddress (char *exp);
extern CORE_ADDR parse_and_eval_address_1 (char **expptr);
- [Simulavr-devel] Problem with gdb (not simulavr), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr), Theodore A. Roth, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble),
Tak Auyeung <=
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), reinhard . jessich, 2002/01/02
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/02
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), reinhard . jessich, 2002/01/02
- [Simulavr-devel] Project Management (was Problem with gdb (not simulavr) (disassemble)), Tak Auyeung, 2002/01/02
- Re: [Simulavr-devel] Project Management (was Problem with gdb (not simulavr) (disassemble)), Theodore A. Roth, 2002/01/02
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/03
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Tak Auyeung, 2002/01/03
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/03
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/01