simulavr-devel
[Top][All Lists]
Advanced

[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);
  

reply via email to

[Prev in Thread] Current Thread [Next in Thread]