[BUG] MI: -target-download

[BUG] MI: -target-download

[Nick Roberts]

In current GDB, the MI command, -target-download, doesn't generate th MI
ouptut as described in the manual.  I think this is due to the change
in load_progress (symfile.c) from 2006-09-21:

  if (bytes == 0 && args->section_sent == 0)
    {
      /* The write is just starting.  Let the user know we've started
	 this section.  */
      ui_out_message (uiout, 0, "Loading section %s, size 0x%s lma 0x%s\n",
		      args->section_name, paddr_nz (args->section_size),
		      paddr_nz (args->lma));
      return;
    }

where GDB returns before getting to deprecated_show_load_progress.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [BUG] MI: -target-download

[Daniel Jacobowitz]

On Wed, Feb 21, 2007 at 08:56:46AM +1300, Nick Roberts wrote:
> 
> In current GDB, the MI command, -target-download, doesn't generate th MI
> ouptut as described in the manual.  I think this is due to the change
> in load_progress (symfile.c) from 2006-09-21:
> 
>   if (bytes == 0 && args->section_sent == 0)
>     {
>       /* The write is just starting.  Let the user know we've started
> 	 this section.  */
>       ui_out_message (uiout, 0, "Loading section %s, size 0x%s lma 0x%s\n",
> 		      args->section_name, paddr_nz (args->section_size),
> 		      paddr_nz (args->lma));
>       return;
>     }
> 
> where GDB returns before getting to deprecated_show_load_progress.

Which output, specifically, are you expecting and not getting?  I
think I was careful not to change the output, but that it already
didn't match the manual, and there was something tricky about fixing
it (I don't remember quite what).  Looking at it now, though, I don't
see anything wrong with the output.

+download,{section=".interp",section-size="19",total-size="76849"}
+download,{section=".interp",section-sent="19",section-size="19",total-sent="19",total-size="76849"}
+download,{section=".note.ABI-tag",section-size="32",total-size="76849"}
+download,{section=".hash",section-size="828",total-size="76849"}
+download,{section=".dynsym",section-size="1728",total-size="76849"}
...
+download,{section=".data",section-size="268",total-size="76849"}
^done,address="0x8049ae0",load-size="75777",transfer-rate="5051800",write-rate="459"

-- 
Daniel Jacobowitz
CodeSourcery

Re: [BUG] MI: -target-download

[Nick Roberts]

 > Which output, specifically, are you expecting and not getting?

All of it.  I just get the CLI output.  I should say this is GDB 6.6.

 >                                                                 I
 > think I was careful not to change the output, but that it already
 > didn't match the manual, and there was something tricky about fixing
 > it (I don't remember quite what).  Looking at it now, though, I don't
 > see anything wrong with the output.
 > 
 > +download,{section=".interp",section-size="19",total-size="76849"}
 > +download,{section=".interp",section-sent="19",section-size="19",total-sent="19",total-size="76849"}
 > +download,{section=".note.ABI-tag",section-size="32",total-size="76849"}
 > +download,{section=".hash",section-size="828",total-size="76849"}
 > +download,{section=".dynsym",section-size="1728",total-size="76849"}
 > ...
 > +download,{section=".data",section-size="268",total-size="76849"}
 > ^done,address="0x8049ae0",load-size="75777",transfer-rate="5051800",write-rate="459"

I don't get this at all.  I was testing cross-debugging (target=arm-elf,
host=i386-redhat-linux-gnu) and used the builtin simulator:

install/bin/arm-elf-gdb -i=mi hello1
~"GNU gdb 6.6\n"
~"Copyright (C) 2006 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\n "
~"welcome to change it and/or distribute copies of it under certain conditions.\ n"
~"Type \"show copying\" to see the conditions.\n"
~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\ n"
~"This GDB was configured as \"--host=i686-pc-linux-gnu --target=arm-elf\"...\n"
(gdb)
-target-select sim
~"Connected to the simulator.\n"
^connected
(gdb)
-target-download
~"Loading section .init, size 0x20 vma 0x8000\n"
~"Loading section .text, size 0x8c18 vma 0x8020\n"
~"Loading section .fini, size 0x1c vma 0x10c38\n"
~"Loading section .rodata, size 0x238 vma 0x10c54\n"
~"Loading section .eh_frame, size 0x4 vma 0x10e8c\n"
~"Loading section .ctors, size 0x8 vma 0x10f90\n"
~"Loading section .dtors, size 0x8 vma 0x10f98\n"
~"Loading section .jcr, size 0x4 vma 0x10fa0\n"
~"Loading section .data, size 0x948 vma 0x10fa4\n"
~"Start address 0x8100\n"
~"Transfer rate: 311136 bits in <1 sec.\n"
^done
(gdb)



-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [BUG] MI: -target-download

[Daniel Jacobowitz]

On Wed, Feb 21, 2007 at 09:22:38AM +1300, Nick Roberts wrote:
> All of it.  I just get the CLI output.  I should say this is GDB 6.6.

Hmm.  I tested several versions from GDB 6.3.90 through CVS HEAD and
they all worked.  I was using gdbserver, though - load works just well
enough with it to test GDB, though don't try to run the result.

This looks specific to the simulator.  Take a look at
sim/common/sim-load.c:

              if (verbose_p)
                {
                  xprintf (callback, "Loading section %s, size 0x%lx %s ",
                           bfd_get_section_name (result_bfd, s),
                           (unsigned long) size,
                           (lma_p ? "lma" : "vma"));
                  xprintf_bfd_vma (callback, lma);
                  xprintf (callback, "\n");
                }

Whoops.  It's got its own copy, it isn't using the GDB load routine at
all.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [BUG] MI: -target-download

[Nick Roberts]

 > This looks specific to the simulator.  Take a look at
 > sim/common/sim-load.c:
 > 
 >               if (verbose_p)
 >                 {
 >                   xprintf (callback, "Loading section %s, size 0x%lx %s ",
 >                            bfd_get_section_name (result_bfd, s),
 >                            (unsigned long) size,
 >                            (lma_p ? "lma" : "vma"));
 >                   xprintf_bfd_vma (callback, lma);
 >                   xprintf (callback, "\n");
 >                 }
 > 
 > Whoops.  It's got its own copy, it isn't using the GDB load routine at
 > all.

OK, I see that I jumped to the wrong conclusion.  I don't use it anyway but I
had thought it might be a simple fix to symfile.c.  Might as well leave things
as they are.

Thanks.

-- 
Nick                                           http://www.inet.net.nz/~nickrob