Re: R: [PATCH] PR gdb/13519, disassemble command attempts to disassemble SRAM rather than program memory.

[Simon Marchi <simark at simark dot ca>]

On 2019-06-15 4:14 p.m., cristiano de alti wrote:
> Hi,
>   Is there any chance this will be ever merged?
> See
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=13519
> 
> Thanks,
>   Cristiano
> 
> ________________________________
> Da: Cristiano De Alti <cristiano_dealti@hotmail.com>
> Inviato: giovedì 17 marzo 2016 23:25
> A: gdb-patches@sourceware.org
> Cc: Cristiano De Alti
> Oggetto: [PATCH] PR gdb/13519, disassemble command attempts to disassemble SRAM rather than program memory.
> 
> gdb/ChangeLog:
> 2016-03-17  Cristiano De Alti  <cristiano_dealti@hotmail.com>
> 
>         PR gdb/13519
>         * avr-tdep.c (avr_integer_to_address): return data or
>         code address accordingly to the second 'type' argument
>         of the function.
> ---
>  gdb/avr-tdep.c |    5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/avr-tdep.c b/gdb/avr-tdep.c
> index 088fe51..993e92b 100644
> --- a/gdb/avr-tdep.c
> +++ b/gdb/avr-tdep.c
> @@ -362,7 +362,10 @@ avr_integer_to_address (struct gdbarch *gdbarch,
>  {
>    ULONGEST addr = unpack_long (type, buf);
> 
> -  return avr_make_saddr (addr);
> +  if (TYPE_DATA_SPACE (type))
> +    return avr_make_saddr (addr);
> +  else
> +    return avr_make_iaddr (addr);
>  }
> 
>  static CORE_ADDR
> --
> 1.7.10.4
> 

Hi Cristiano,

This also changes the default behavior of the x (examine memory) command, is it expected?

Before:

  $ ~/build/binutils-gdb/gdb/gdb a.out -ex "tar rem :1234" -ex "b main" -ex c
  (gdb) x 0x10
  0x800010:	0x00000000

After:

  $ ~/build/binutils-gdb/gdb/gdb a.out -ex "tar rem :1234" -ex "b main" -ex c
  (gdb) x 0x10
  0x10 <__vectors+16>:	0xc022c023

So while this fixes "disassemble" to use code/flash addresses (which makes sense), it changes
the behavior for "x".  I think that people are most likely interested in data/sram when using
the "x" command (except maybe if using "x/i", as was mentioned in bug 13519).

Simon