should gdb require '.text' and '.data' sections?

should gdb require '.text' and '.data' sections?

[josef ezra]

Hello

I'm trying to debug a symbol file that has no '.text' section. Unlike 5.0
version, the new SECT_OFF_TEXT(objfile) macro calls (no-return) internal
error and prevent the read.

Should gdb work that way (requiring '.text' and '.data' sections)?

If not, can we consider the first sections flagged 'SEC_CODE'/'SEC_DATA' as
substitutes? Or maybe better have a default 0/1 values (like 5.0)? Both
should work in my case.

- Jezra

Re: should gdb require '.text' and '.data' sections?

[Michael Snyder]

josef ezra wrote:
> 
> Hello
> 
> I'm trying to debug a symbol file that has no '.text' section. Unlike 5.0
> version, the new SECT_OFF_TEXT(objfile) macro calls (no-return) internal
> error and prevent the read.
> 
> Should gdb work that way (requiring '.text' and '.data' sections)?
> 
> If not, can we consider the first sections flagged 'SEC_CODE'/'SEC_DATA' as
> substitutes? Or maybe better have a default 0/1 values (like 5.0)? Both
> should work in my case.

I agree, gdb should not require .text and .data.  For one thing, 
a simple embedded assembler program might have no initialized data.  
For another, those segments might be called something else.

Re: should gdb require '.text' and '.data' sections?

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

Michael Snyder wrote:

>josef ezra wrote:
>
>>Hello
>>
>>I'm trying to debug a symbol file that has no '.text' section. Unlike 5.0
>>version, the new SECT_OFF_TEXT(objfile) macro calls (no-return) internal
>>error and prevent the read.
>>
>>Should gdb work that way (requiring '.text' and '.data' sections)?
>>
>>If not, can we consider the first sections flagged 'SEC_CODE'/'SEC_DATA' as
>>substitutes? Or maybe better have a default 0/1 values (like 5.0)? Both
>>should work in my case.
>>
>
>I agree, gdb should not require .text and .data.  For one thing, 
>a simple embedded assembler program might have no initialized data.  
>For another, those segments might be called something else.
>

Thanks Michael

This patch will set the index of the first section that contains 
CODE/DATA flag as the default value of
objfile->sect_index_code/data.

- jezra

bfd/ChangeLog:
* section.c (bfd_get_first_code_section): new function.
* section.c (bfd_get_first_data_section): new function.
* bfd-in2.h: Regenerated.

gdb/ChangeLog:
* symfile.c ( default_symfile_offsets): default index for '.text' and 
'.data' sections.





[-- Attachment #2: sect_index_gdb.pat --]
[-- Type: text/plain, Size: 712 bytes --]

Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.58
diff -u -3 -r1.58 symfile.c
--- gdb/symfile.c	29 Mar 2002 01:09:27 -0000	1.58
+++ gdb/symfile.c	22 Apr 2002 13:05:51 -0000
@@ -522,10 +522,14 @@
      .rodata sections. */
 
   sect = bfd_get_section_by_name (objfile->obfd, ".text");
+  if (!sect)
+    sect = bfd_get_first_code_section (objfile->obfd); 
   if (sect) 
     objfile->sect_index_text = sect->index;
 
   sect = bfd_get_section_by_name (objfile->obfd, ".data");
+  if (!sect)
+    sect = bfd_get_first_data_section (objfile->obfd) ; 
   if (sect) 
     objfile->sect_index_data = sect->index;
 

[-- Attachment #3: sect_index_bfd.pat --]
[-- Type: text/plain, Size: 1910 bytes --]

Index: bfd/section.c
===================================================================
RCS file: /cvs/src/src/bfd/section.c,v
retrieving revision 1.44
diff -u -3 -r1.44 section.c
--- bfd/section.c	30 Jan 2002 18:12:16 -0000	1.44
+++ bfd/section.c	19 Apr 2002 21:19:44 -0000
@@ -772,6 +772,56 @@
 
 /*
 FUNCTION
+	bfd_get_first_code_section
+
+SYNOPSIS
+	asection *bfd_get_first_code_section(bfd *abfd);
+
+DESCRIPTION
+	Run through @var{abfd} and return the first
+	<<asection>>s whose flagged SEC_CODE, <<NULL>> 
+	@xref{Sections} if none (just in case .. )
+*/
+
+asection *
+bfd_get_first_code_section (abfd)
+     bfd *abfd;
+{
+  asection *sect;
+
+  for (sect = abfd->sections; sect != NULL; sect = sect->next)
+    if (sect->flags & SEC_CODE)
+      return sect;
+  return NULL;
+}
+
+/*
+FUNCTION
+	bfd_get_first_data_section
+
+SYNOPSIS
+	asection *bfd_get_first_data_section(bfd *abfd);
+
+DESCRIPTION
+	Run through @var{abfd} and return the first
+	<<asection>>s whose flagged SEC_DATA, <<NULL>> 
+	@xref{Sections} if none (just in case .. )
+*/
+
+asection *
+bfd_get_first_data_section (abfd)
+     bfd *abfd;
+{
+  asection *sect;
+
+  for (sect = abfd->sections; sect != NULL; sect = sect->next)
+    if (sect->flags & SEC_DATA)
+      return sect;
+  return NULL;
+}
+
+/*
+FUNCTION
 	bfd_get_unique_section_name
 
 SYNOPSIS
Index: bfd/bfd-in2.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in2.h,v
retrieving revision 1.149
diff -u -3 -r1.149 bfd-in2.h
--- bfd/bfd-in2.h	4 Apr 2002 19:53:34 -0000	1.149
+++ bfd/bfd-in2.h	19 Apr 2002 21:19:45 -0000
@@ -1401,6 +1401,12 @@
 
 asection *
 bfd_get_section_by_name PARAMS ((bfd *abfd, const char *name));
+
+asection *
+bfd_get_first_code_section PARAMS ((bfd *abfd));
+
+asection *
+bfd_get_first_data_section PARAMS ((bfd *abfd));
 
 char *
 bfd_get_unique_section_name PARAMS ((bfd *abfd,

[RFA] should gdb require '.text' and '.data' sections?

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

Michael Snyder wrote:

>josef ezra wrote:
>
>>Hello
>>
>>I'm trying to debug a symbol file that has no '.text' section. Unlike 5.0
>>version, the new SECT_OFF_TEXT(objfile) macro calls (no-return) internal
>>error and prevent the read.
>>
>>Should gdb work that way (requiring '.text' and '.data' sections)?
>>
>>If not, can we consider the first sections flagged 'SEC_CODE'/'SEC_DATA' as
>>substitutes? Or maybe better have a default 0/1 values (like 5.0)? Both
>>should work in my case.
>>
>
>I agree, gdb should not require .text and .data.  For one thing, 
>a simple embedded assembler program might have no initialized data.  
>For another, those segments might be called something else.
>

This patch will set objfile->sect_index_code/data index to the first 
section that contains CODE/DATA flag when no section was named 
'.text'/'.data'.

- jezra

bfd/ChangeLog:
* section.c (bfd_get_first_code_section): new function.
* section.c (bfd_get_first_data_section): new function.
* bfd-in2.h: Regenerated via 'make headers'.

gdb/ChangeLog:
* symfile.c ( default_symfile_offsets): default index for '.text' and 
'.data' sections.


[-- Attachment #2: sect_index_bfd.pat --]
[-- Type: text/plain, Size: 1910 bytes --]

Index: bfd/section.c
===================================================================
RCS file: /cvs/src/src/bfd/section.c,v
retrieving revision 1.44
diff -u -3 -r1.44 section.c
--- bfd/section.c	30 Jan 2002 18:12:16 -0000	1.44
+++ bfd/section.c	19 Apr 2002 21:19:44 -0000
@@ -772,6 +772,56 @@
 
 /*
 FUNCTION
+	bfd_get_first_code_section
+
+SYNOPSIS
+	asection *bfd_get_first_code_section(bfd *abfd);
+
+DESCRIPTION
+	Run through @var{abfd} and return the first
+	<<asection>>s whose flagged SEC_CODE, <<NULL>> 
+	@xref{Sections} if none (just in case .. )
+*/
+
+asection *
+bfd_get_first_code_section (abfd)
+     bfd *abfd;
+{
+  asection *sect;
+
+  for (sect = abfd->sections; sect != NULL; sect = sect->next)
+    if (sect->flags & SEC_CODE)
+      return sect;
+  return NULL;
+}
+
+/*
+FUNCTION
+	bfd_get_first_data_section
+
+SYNOPSIS
+	asection *bfd_get_first_data_section(bfd *abfd);
+
+DESCRIPTION
+	Run through @var{abfd} and return the first
+	<<asection>>s whose flagged SEC_DATA, <<NULL>> 
+	@xref{Sections} if none (just in case .. )
+*/
+
+asection *
+bfd_get_first_data_section (abfd)
+     bfd *abfd;
+{
+  asection *sect;
+
+  for (sect = abfd->sections; sect != NULL; sect = sect->next)
+    if (sect->flags & SEC_DATA)
+      return sect;
+  return NULL;
+}
+
+/*
+FUNCTION
 	bfd_get_unique_section_name
 
 SYNOPSIS
Index: bfd/bfd-in2.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in2.h,v
retrieving revision 1.149
diff -u -3 -r1.149 bfd-in2.h
--- bfd/bfd-in2.h	4 Apr 2002 19:53:34 -0000	1.149
+++ bfd/bfd-in2.h	19 Apr 2002 21:19:45 -0000
@@ -1401,6 +1401,12 @@
 
 asection *
 bfd_get_section_by_name PARAMS ((bfd *abfd, const char *name));
+
+asection *
+bfd_get_first_code_section PARAMS ((bfd *abfd));
+
+asection *
+bfd_get_first_data_section PARAMS ((bfd *abfd));
 
 char *
 bfd_get_unique_section_name PARAMS ((bfd *abfd,

[-- Attachment #3: sect_index_gdb.pat --]
[-- Type: text/plain, Size: 712 bytes --]

Index: gdb/symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.58
diff -u -3 -r1.58 symfile.c
--- gdb/symfile.c	29 Mar 2002 01:09:27 -0000	1.58
+++ gdb/symfile.c	22 Apr 2002 13:05:51 -0000
@@ -522,10 +522,14 @@
      .rodata sections. */
 
   sect = bfd_get_section_by_name (objfile->obfd, ".text");
+  if (!sect)
+    sect = bfd_get_first_code_section (objfile->obfd); 
   if (sect) 
     objfile->sect_index_text = sect->index;
 
   sect = bfd_get_section_by_name (objfile->obfd, ".data");
+  if (!sect)
+    sect = bfd_get_first_data_section (objfile->obfd) ; 
   if (sect) 
     objfile->sect_index_data = sect->index;
 

Request for new gdb command: 'info orientation'

[Josef Ezra]

Hi all

While writing a perl gui for gdb, I had to add a new command. It looks 
like this:

(gdb) info orientation main
0x00034960:753
0x00034b44:757
0x00034b48:761
0x00034b50:759
0x00034b54:761
0x00034b68:763
0x00034b70:772
(gdb)

and associate addresses with line numbers. This information allow 
merging the disassemble with the sources without executing 'info line' 
command for each address, since the last took too long (the difference 
between O(n^2) to O(n)).
(The command was also useful for analyzing patches and code changes.)

Is there an existing way of doing it? If not, will you consider adding 
this (or similar) command?

- jezra

The perl gui (temporally named 'sgdb') is in the process of becoming an 
open source. Snapshots can be found at http://sgdb.sourceforge.net

The linkage between perl and gdb can be downloaded from CPAN. The module 
name is Devel::GDB.

Re: Request for new gdb command: 'info orientation'

[Andrew Cagney]

> Hi all
> 
> While writing a perl gui for gdb, I had to add a new command. It looks like this:
> 
> (gdb) info orientation main
> 0x00034960:753
> 0x00034b44:757
> 0x00034b48:761
> 0x00034b50:759
> 0x00034b54:761
> 0x00034b68:763
> 0x00034b70:772
> (gdb)
> 
> and associate addresses with line numbers. This information allow merging the disassemble with the sources without executing 'info line' command for each address, since the last took too long (the difference between O(n^2) to O(n)).
> (The command was also useful for analyzing patches and code changes.)
> 
> Is there an existing way of doing it? If not, will you consider adding this (or similar) command?

FYI, there is already an equivalent mechanism.  Please have a look at:

http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC283

Andrew

Re: Request for new gdb command: 'info orientation'

[Michael Snyder]

Josef Ezra wrote:
> 
> Hi all
> 
> While writing a perl gui for gdb, I had to add a new command. It looks
> like this:
> 
> (gdb) info orientation main
> 0x00034960:753
> 0x00034b44:757
> 0x00034b48:761
> 0x00034b50:759
> 0x00034b54:761
> 0x00034b68:763
> 0x00034b70:772
> (gdb)
> 
> and associate addresses with line numbers. This information allow
> merging the disassemble with the sources without executing 'info line'
> command for each address, since the last took too long (the difference
> between O(n^2) to O(n)).
> (The command was also useful for analyzing patches and code changes.)

I like it as maybe a maintainer command (or even a user one, if
you think users might gain something from it.

I don't like the name, though -- "info orientation" doesn't say
anything to me.  Maybe "info lines"?  Or, as a maintainer command, 
"info sal"?

Re: Request for new gdb command: 'info orientation'

[Josef Ezra]

Michael Snyder wrote:
> Josef Ezra wrote:
> 
>>Hi all
>>
>>While writing a perl gui for gdb, I had to add a new command. It looks
>>like this:
>>
>>(gdb) info orientation main
>>0x00034960:753
>>0x00034b44:757
>>0x00034b48:761
>>0x00034b50:759
>>0x00034b54:761
>>0x00034b68:763
>>0x00034b70:772
>>(gdb)
>>
>>and associate addresses with line numbers. This information allow
>>merging the disassemble with the sources without executing 'info line'
>>command for each address, since the last took too long (the difference
>>between O(n^2) to O(n)).
>>(The command was also useful for analyzing patches and code changes.)
> 
> 
> I like it as maybe a maintainer command (or even a user one, if
> you think users might gain something from it.
> 
> I don't like the name, though -- "info orientation" doesn't say
> anything to me.  Maybe "info lines"?  Or, as a maintainer command, 
> "info sal"?
> 

How about 'maintenance info-lines'?

[RFA] new command: 'maintenance info lines'

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 572 bytes --]

Michael Snyder wrote:
> 
> I like it as maybe a maintainer command (or even a user one, if
> you think users might gain something from it.
> 
> I don't like the name, though -- "info orientation" doesn't say
> anything to me.  Maybe "info lines"?  Or, as a maintainer command, 
> "info sal"?
> 



Following the line of 'maintenance info breakpoints / sections / 
sol-threads' commands, I'd like to suggest 'maintenance info lines' for 
this line-address dump.

  	- jezra

* printcmd.c (maintenance_info_lines): created
              (_initialize_printcmd): add command


[-- Attachment #2: m-i-lines.patch --]
[-- Type: text/plain, Size: 3185 bytes --]

Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.39
diff -u -5 -r1.39 printcmd.c
--- printcmd.c	11 May 2002 23:48:23 -0000	1.39
+++ printcmd.c	17 Jun 2002 18:36:58 -0000
@@ -2383,10 +2383,79 @@
 
   return TARGET_PRINT_INSN (memaddr, TARGET_PRINT_INSN_INFO);
 }
 \f
 
+/*
+  Print range as 'Address:Line' pairs. This command might be usefull
+  to associate sources and assembly commands. 
+*/
+
+static void
+maintenance_info_lines (char *arg, int from_tty)
+{
+  CORE_ADDR low, high;
+  {
+    char *name;
+    CORE_ADDR pc, pc_masked;
+    char *space_index;
+    name = NULL;
+    if (!arg)
+      {
+        if (!selected_frame)
+          error ("No frame selected.\n");
+
+        pc = get_frame_pc (selected_frame);
+        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
+          error ("No function contains program counter for selected frame.\n");
+
+        low += FUNCTION_START_OFFSET;
+      }
+    else if (!(space_index = (char *) strchr (arg, ' ')))
+      {
+        /* One argument.  */
+        pc = parse_and_eval_address (arg);
+        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
+          error ("No function contains specified address.\n");
+        low += FUNCTION_START_OFFSET;
+      }
+    else
+      {
+        /* Two arguments.  */
+        *space_index = '\0';
+        low = parse_and_eval_address (arg);
+        high = parse_and_eval_address (space_index + 1);
+      }
+  }
+  /* OK, we got the low-high range, what now? */
+  {
+    struct symtab *symtab ;
+    struct linetable_entry *le ;
+    int i, nitems ;
+    symtab = find_pc_symtab (low ) ;
+    if (symtab && symtab->linetable) 
+      {
+    
+        le = symtab->linetable->item ;
+        nitems = symtab->linetable->nitems ;
+
+                                /* skip to low */
+        for (i = 0 ; 
+             (i < nitems - 1) && (le[i + 1].pc < low) ; 
+             i++ ) ;
+
+                                /* and print all the way to high */
+        for (; (i < nitems -1) && (le[i].pc <= high); i++ )
+          {
+            if (le[i].pc   != le[i+1].pc   ) 
+                                /* optimized line ? */
+              printf_filtered ("0x%08x:%d\n", (unsigned) le[i].pc, le[i].line ) ;
+          }
+      }
+  }
+}
+
 void
 _initialize_printcmd (void)
 {
   struct cmd_list_element *c;
 
@@ -2561,7 +2630,13 @@
 
   examine_b_type = init_type (TYPE_CODE_INT, 1, 0, "examine_b_type", NULL);
   examine_h_type = init_type (TYPE_CODE_INT, 2, 0, "examine_h_type", NULL);
   examine_w_type = init_type (TYPE_CODE_INT, 4, 0, "examine_w_type", NULL);
   examine_g_type = init_type (TYPE_CODE_INT, 8, 0, "examine_g_type", NULL);
+  add_cmd ( "lines", class_maintenance, maintenance_info_lines,
+            concat ("Dump a line-address table a specified section of memory.\n\
+Default is the function surrounding the pc of the selected frame.\n\
+With a single argument, the function surrounding that address is dumped.\n\
+Two arguments are taken as a range of memory to dump.", NULL ), 
+            &maintenanceinfolist) ; 
 
 }

Re: [RFA] new command: 'maintenance info lines'

[Eli Zaretskii]

On Mon, 17 Jun 2002, Josef Ezra wrote:

> Following the line of 'maintenance info breakpoints / sections / 
> sol-threads' commands, I'd like to suggest 'maintenance info lines' for 
> this line-address dump.
> 
>   	- jezra
> 
> * printcmd.c (maintenance_info_lines): created
>               (_initialize_printcmd): add command

Please also consider adding a suitable description to gdb.texinfo.
TIA

Re: [RFA] new command: 'maintenance info lines'

[josef ezra]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

Eli Zaretskii wrote:
>
> On Mon, 17 Jun 2002, Josef Ezra wrote:
>
> > Following the line of 'maintenance info breakpoints / sections /
> > sol-threads' commands, I'd like to suggest 'maintenance info lines' for
> > this line-address dump.
> >
> >   - jezra
> >
> > * printcmd.c (maintenance_info_lines): created
> >               (_initialize_printcmd): add command
>
> Please also consider adding a suitable description to gdb.texinfo.
> TIA
>

I'm adding this gdb.textinfo entry (should I re-commit the whole thing?)

- jezra


[-- Attachment #2: diff --]
[-- Type: application/octet-stream, Size: 766 bytes --]

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.102
diff -u -3 -r1.102 gdb.texinfo
--- gdb.texinfo	11 Jun 2002 20:36:57 -0000	1.102
+++ gdb.texinfo	18 Jun 2002 20:40:29 -0000
@@ -4360,6 +4360,13 @@
 can set @var{instruction-set} to either @code{intel} or @code{att}.
 The default is @code{att}, the AT&T flavor used by default by Unix
 assemblers for x86-based targets.
+
+@kindex maint info lines
+@item maint info lines
+This command takes same parameters as @code{disassemble}, but only 
+dumps an 'address:line' pairs.  Every pair means: "from this address 
+to the next pair, the code was generated by that line".  
+
 @end table
 
 

Re: [RFA] new command: 'maintenance info lines'

[Michael Snyder]

Josef Ezra wrote:
> 
> Michael Snyder wrote:
> >
> > I like it as maybe a maintainer command (or even a user one, if
> > you think users might gain something from it.
> >
> > I don't like the name, though -- "info orientation" doesn't say
> > anything to me.  Maybe "info lines"?  Or, as a maintainer command,
> > "info sal"?
> >
> 
> Following the line of 'maintenance info breakpoints / sections /
> sol-threads' commands, I'd like to suggest 'maintenance info lines' for
> this line-address dump.

Works for me.

> 
>         - jezra
> 
> * printcmd.c (maintenance_info_lines): created
>               (_initialize_printcmd): add command
> 
>   ------------------------------------------------------------------------
> Index: printcmd.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/printcmd.c,v
> retrieving revision 1.39
> diff -u -5 -r1.39 printcmd.c
> --- printcmd.c  11 May 2002 23:48:23 -0000      1.39
> +++ printcmd.c  17 Jun 2002 18:36:58 -0000
> @@ -2383,10 +2383,79 @@
> 
>    return TARGET_PRINT_INSN (memaddr, TARGET_PRINT_INSN_INFO);
>  }
> 
> 
> +/*
> +  Print range as 'Address:Line' pairs. This command might be usefull
> +  to associate sources and assembly commands.
> +*/
> +
> +static void
> +maintenance_info_lines (char *arg, int from_tty)
> +{
> +  CORE_ADDR low, high;
> +  {
> +    char *name;
> +    CORE_ADDR pc, pc_masked;
> +    char *space_index;
> +    name = NULL;
> +    if (!arg)
> +      {
> +        if (!selected_frame)
> +          error ("No frame selected.\n");
> +
> +        pc = get_frame_pc (selected_frame);
> +        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
> +          error ("No function contains program counter for selected frame.\n");
> +
> +        low += FUNCTION_START_OFFSET;
> +      }
> +    else if (!(space_index = (char *) strchr (arg, ' ')))
> +      {
> +        /* One argument.  */
> +        pc = parse_and_eval_address (arg);
> +        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
> +          error ("No function contains specified address.\n");
> +        low += FUNCTION_START_OFFSET;
> +      }
> +    else
> +      {
> +        /* Two arguments.  */
> +        *space_index = '\0';
> +        low = parse_and_eval_address (arg);
> +        high = parse_and_eval_address (space_index + 1);
> +      }
> +  }
> +  /* OK, we got the low-high range, what now? */
> +  {
> +    struct symtab *symtab ;
> +    struct linetable_entry *le ;
> +    int i, nitems ;
> +    symtab = find_pc_symtab (low ) ;
> +    if (symtab && symtab->linetable)
> +      {
> +
> +        le = symtab->linetable->item ;
> +        nitems = symtab->linetable->nitems ;
> +
> +                                /* skip to low */
> +        for (i = 0 ;
> +             (i < nitems - 1) && (le[i + 1].pc < low) ;
> +             i++ ) ;
> +
> +                                /* and print all the way to high */
> +        for (; (i < nitems -1) && (le[i].pc <= high); i++ )
> +          {
> +            if (le[i].pc   != le[i+1].pc   )
> +                                /* optimized line ? */
> +              printf_filtered ("0x%08x:%d\n", (unsigned) le[i].pc, le[i].line ) ;
> +          }
> +      }
> +  }
> +}
> +
>  void
>  _initialize_printcmd (void)
>  {
>    struct cmd_list_element *c;
> 
> @@ -2561,7 +2630,13 @@
> 
>    examine_b_type = init_type (TYPE_CODE_INT, 1, 0, "examine_b_type", NULL);
>    examine_h_type = init_type (TYPE_CODE_INT, 2, 0, "examine_h_type", NULL);
>    examine_w_type = init_type (TYPE_CODE_INT, 4, 0, "examine_w_type", NULL);
>    examine_g_type = init_type (TYPE_CODE_INT, 8, 0, "examine_g_type", NULL);
> +  add_cmd ( "lines", class_maintenance, maintenance_info_lines,
> +            concat ("Dump a line-address table a specified section of memory.\n\
> +Default is the function surrounding the pc of the selected frame.\n\
> +With a single argument, the function surrounding that address is dumped.\n\
> +Two arguments are taken as a range of memory to dump.", NULL ),
> +            &maintenanceinfolist) ;
> 
>  }

Re: [RFA] new command: 'maintenance info lines'

[Michael Snyder]

josef ezra wrote:
> 
> Eli Zaretskii wrote:
> >
> > On Mon, 17 Jun 2002, Josef Ezra wrote:
> >
> > > Following the line of 'maintenance info breakpoints / sections /
> > > sol-threads' commands, I'd like to suggest 'maintenance info lines' for
> > > this line-address dump.
> > >
> > >   - jezra
> > >
> > > * printcmd.c (maintenance_info_lines): created
> > >               (_initialize_printcmd): add command
> >
> > Please also consider adding a suitable description to gdb.texinfo.
> > TIA
> >
> 
> I'm adding this gdb.textinfo entry (should I re-commit the whole thing?)

No, if you've already committed the earlier part, you don't have to
do it again.  If Eli approves the Docs change, you can commit it 
separately.

Re: [RFA] new command: 'maintenance info lines'

[Eli Zaretskii]

On Tue, 18 Jun 2002, josef ezra wrote:

> I'm adding this gdb.textinfo entry

Thanks.  A couple of minor comments:

> +This command takes same parameters as @code{disassemble}, but only 
> +dumps an 'address:line' pairs.

`address' and `line' stand for something else, so they should have the 
@var markup:

   ... @code{@var{address}:@var{line}} pairs ...

> +  Every pair means: "from this address 
> +to the next pair, the code was generated by that line".  

Please use `` and '' rather than " in Texinfo.  The former will look much 
better when typeset by TeX in the printed manual (in the Info output, 
they are converted to " automatically).

Other than that, the documentation patch is approved.

Re: [RFA] new command: 'maintenance info lines'

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Eli Zaretskii wrote:
> On Tue, 18 Jun 2002, josef ezra wrote:
> 
> 
>>I'm adding this gdb.textinfo entry
> 
> 
> Thanks.  A couple of minor comments:
> 
> 
>>+This command takes same parameters as @code{disassemble}, but only 
>>+dumps an 'address:line' pairs.
> 
> 
> `address' and `line' stand for something else, so they should have the 
> @var markup:
> 
>    ... @code{@var{address}:@var{line}} pairs ...
> 
> 
>>+  Every pair means: "from this address 
>>+to the next pair, the code was generated by that line".  
> 
> 
> Please use `` and '' rather than " in Texinfo.  The former will look much 
> better when typeset by TeX in the printed manual (in the Info output, 
> they are converted to " automatically).
> 
> Other than that, the documentation patch is approved.
> 

thanks.
Updated patch attached ...


[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 767 bytes --]

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.102
diff -u -3 -r1.102 gdb.texinfo
--- gdb.texinfo	11 Jun 2002 20:36:57 -0000	1.102
+++ gdb.texinfo	19 Jun 2002 14:10:47 -0000
@@ -4360,6 +4360,13 @@
 can set @var{instruction-set} to either @code{intel} or @code{att}.
 The default is @code{att}, the AT&T flavor used by default by Unix
 assemblers for x86-based targets.
+
+@kindex maint info lines
+@item maint info lines
+This command takes same parameters as @code{disassemble}, but only 
+dumps an @code{@var{address}:@var{line}} pairs.  Every pair means: ``from this 
+@var{address} forward, the code was generated by that @var{line}''.  
+
 @end table
 
 

[RFA] new command: 'maintenance info lines'

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Michael Snyder wrote:
> Josef Ezra wrote:
> 
>>Michael Snyder wrote:
>>
>>>I like it as maybe a maintainer command (or even a user one, if
>>>you think users might gain something from it.
>>>
>>>I don't like the name, though -- "info orientation" doesn't say
>>>anything to me.  Maybe "info lines"?  Or, as a maintainer command,
>>>"info sal"?
>>>
>>
>>Following the line of 'maintenance info breakpoints / sections /
>>sol-threads' commands, I'd like to suggest 'maintenance info lines' for
>>this line-address dump.
> 
> 
> Works for me.
> 
> 

hi

It took a while to resolve the legal issues, so I'm re-committing ..

- jezra

* printcmd.c (maintenance_info_lines): created
               (_initialize_printcmd): add command

* doc/gdb.textinfo: add documentation for 'maint info lines'



[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 3783 bytes --]

Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.120
diff -u -3 -r1.120 gdb.texinfo
--- doc/gdb.texinfo	5 Sep 2002 12:13:08 -0000	1.120
+++ doc/gdb.texinfo	5 Sep 2002 21:01:23 -0000
@@ -4362,6 +4362,13 @@
 can set @var{instruction-set} to either @code{intel} or @code{att}.
 The default is @code{att}, the AT&T flavor used by default by Unix
 assemblers for x86-based targets.
+
+@kindex maint info lines
+@item maint info lines
+This command takes same parameters as @code{disassemble}, but only 
+dumps an @code{@var{address}:@var{line}} pairs.  Every pair means: ``from this 
+@var{address} forward, the code was generated by that @var{line}''.  
+
 @end table
 
 
Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.40
diff -u -3 -r1.40 printcmd.c
--- printcmd.c	11 Jul 2002 20:46:19 -0000	1.40
+++ printcmd.c	5 Sep 2002 21:01:23 -0000
@@ -2390,6 +2390,75 @@
 }
 \f
 
+/*
+  Print range as 'Address:Line' pairs. This command might be usefull
+  to associate sources and assembly commands. 
+*/
+
+static void
+maintenance_info_lines (char *arg, int from_tty)
+{
+  CORE_ADDR low, high;
+  {
+    char *name;
+    CORE_ADDR pc, pc_masked;
+    char *space_index;
+    name = NULL;
+    if (!arg)
+      {
+        if (!selected_frame)
+          error ("No frame selected.\n");
+
+        pc = get_frame_pc (selected_frame);
+        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
+          error ("No function contains program counter for selected frame.\n");
+
+        low += FUNCTION_START_OFFSET;
+      }
+    else if (!(space_index = (char *) strchr (arg, ' ')))
+      {
+        /* One argument.  */
+        pc = parse_and_eval_address (arg);
+        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
+          error ("No function contains specified address.\n");
+        low += FUNCTION_START_OFFSET;
+      }
+    else
+      {
+        /* Two arguments.  */
+        *space_index = '\0';
+        low = parse_and_eval_address (arg);
+        high = parse_and_eval_address (space_index + 1);
+      }
+  }
+  /* OK, we got the low-high range, what now? */
+  {
+    struct symtab *symtab ;
+    struct linetable_entry *le ;
+    int i, nitems ;
+    symtab = find_pc_symtab (low ) ;
+    if (symtab && symtab->linetable) 
+      {
+    
+        le = symtab->linetable->item ;
+        nitems = symtab->linetable->nitems ;
+
+                                /* skip to low */
+        for (i = 0 ; 
+             (i < nitems - 1) && (le[i + 1].pc < low) ; 
+             i++ ) ;
+
+                                /* and print all the way to high */
+        for (; (i < nitems -1) && (le[i].pc <= high); i++ )
+          {
+            if (le[i].pc   != le[i+1].pc   ) 
+                                /* optimized line ? */
+              printf_filtered ("0x%08x:%d\n", (unsigned) le[i].pc, le[i].line ) ;
+          }
+      }
+  }
+}
+
 void
 _initialize_printcmd (void)
 {
@@ -2568,5 +2637,11 @@
   examine_h_type = init_type (TYPE_CODE_INT, 2, 0, "examine_h_type", NULL);
   examine_w_type = init_type (TYPE_CODE_INT, 4, 0, "examine_w_type", NULL);
   examine_g_type = init_type (TYPE_CODE_INT, 8, 0, "examine_g_type", NULL);
+  add_cmd ( "lines", class_maintenance, maintenance_info_lines,
+            concat ("Dump a line-address table a specified section of memory.\n\
+Default is the function surrounding the pc of the selected frame.\n\
+With a single argument, the function surrounding that address is dumped.\n\
+Two arguments are taken as a range of memory to dump.", NULL ), 
+            &maintenanceinfolist) ; 
 
 }

Re: [RFA] new command: 'maintenance info lines'

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Michael Snyder wrote:
> Josef Ezra wrote:
> 
>>Michael Snyder wrote:
>>
>>>I like it as maybe a maintainer command (or even a user one, if
>>>you think users might gain something from it.
>>>
>>>I don't like the name, though -- "info orientation" doesn't say
>>>anything to me.  Maybe "info lines"?  Or, as a maintainer command,
>>>"info sal"?
>>>
>>
>>Following the line of 'maintenance info breakpoints / sections /
>>sol-threads' commands, I'd like to suggest 'maintenance info lines' for
>>this line-address dump.
> 
> 
> Works for me.
> 
> 


hi

It took a while to resolve the legal issues, so I'm re-committing ..

- jezra

* printcmd.c (maintenance_info_lines): created
               (_initialize_printcmd): add command

* doc/gdb.textinfo: add documentation for 'maint info lines'



[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 3783 bytes --]

Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.120
diff -u -3 -r1.120 gdb.texinfo
--- doc/gdb.texinfo	5 Sep 2002 12:13:08 -0000	1.120
+++ doc/gdb.texinfo	5 Sep 2002 21:01:23 -0000
@@ -4362,6 +4362,13 @@
 can set @var{instruction-set} to either @code{intel} or @code{att}.
 The default is @code{att}, the AT&T flavor used by default by Unix
 assemblers for x86-based targets.
+
+@kindex maint info lines
+@item maint info lines
+This command takes same parameters as @code{disassemble}, but only 
+dumps an @code{@var{address}:@var{line}} pairs.  Every pair means: ``from this 
+@var{address} forward, the code was generated by that @var{line}''.  
+
 @end table
 
 
Index: printcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/printcmd.c,v
retrieving revision 1.40
diff -u -3 -r1.40 printcmd.c
--- printcmd.c	11 Jul 2002 20:46:19 -0000	1.40
+++ printcmd.c	5 Sep 2002 21:01:23 -0000
@@ -2390,6 +2390,75 @@
 }
 \f
 
+/*
+  Print range as 'Address:Line' pairs. This command might be usefull
+  to associate sources and assembly commands. 
+*/
+
+static void
+maintenance_info_lines (char *arg, int from_tty)
+{
+  CORE_ADDR low, high;
+  {
+    char *name;
+    CORE_ADDR pc, pc_masked;
+    char *space_index;
+    name = NULL;
+    if (!arg)
+      {
+        if (!selected_frame)
+          error ("No frame selected.\n");
+
+        pc = get_frame_pc (selected_frame);
+        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
+          error ("No function contains program counter for selected frame.\n");
+
+        low += FUNCTION_START_OFFSET;
+      }
+    else if (!(space_index = (char *) strchr (arg, ' ')))
+      {
+        /* One argument.  */
+        pc = parse_and_eval_address (arg);
+        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
+          error ("No function contains specified address.\n");
+        low += FUNCTION_START_OFFSET;
+      }
+    else
+      {
+        /* Two arguments.  */
+        *space_index = '\0';
+        low = parse_and_eval_address (arg);
+        high = parse_and_eval_address (space_index + 1);
+      }
+  }
+  /* OK, we got the low-high range, what now? */
+  {
+    struct symtab *symtab ;
+    struct linetable_entry *le ;
+    int i, nitems ;
+    symtab = find_pc_symtab (low ) ;
+    if (symtab && symtab->linetable) 
+      {
+    
+        le = symtab->linetable->item ;
+        nitems = symtab->linetable->nitems ;
+
+                                /* skip to low */
+        for (i = 0 ; 
+             (i < nitems - 1) && (le[i + 1].pc < low) ; 
+             i++ ) ;
+
+                                /* and print all the way to high */
+        for (; (i < nitems -1) && (le[i].pc <= high); i++ )
+          {
+            if (le[i].pc   != le[i+1].pc   ) 
+                                /* optimized line ? */
+              printf_filtered ("0x%08x:%d\n", (unsigned) le[i].pc, le[i].line ) ;
+          }
+      }
+  }
+}
+
 void
 _initialize_printcmd (void)
 {
@@ -2568,5 +2637,11 @@
   examine_h_type = init_type (TYPE_CODE_INT, 2, 0, "examine_h_type", NULL);
   examine_w_type = init_type (TYPE_CODE_INT, 4, 0, "examine_w_type", NULL);
   examine_g_type = init_type (TYPE_CODE_INT, 8, 0, "examine_g_type", NULL);
+  add_cmd ( "lines", class_maintenance, maintenance_info_lines,
+            concat ("Dump a line-address table a specified section of memory.\n\
+Default is the function surrounding the pc of the selected frame.\n\
+With a single argument, the function surrounding that address is dumped.\n\
+Two arguments are taken as a range of memory to dump.", NULL ), 
+            &maintenanceinfolist) ; 
 
 }

Re: [RFA] new command: 'maintenance info lines'

[Eli Zaretskii]

On Fri, 6 Sep 2002, Josef Ezra wrote:

> * doc/gdb.textinfo: add documentation for 'maint info lines'

Thanks.  Please add a cross-reference to the place where `disassemble' is 
described, so that the reader could find out what arguments does this 
command accept.

Re: [RFA] new command: 'maintenance info lines'

[Josef Ezra]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Eli Zaretskii wrote:

>On Fri, 6 Sep 2002, Josef Ezra wrote:
>  
>
>>* doc/gdb.textinfo: add documentation for 'maint info lines'
>>    
>>
>
>Thanks.  Please add a cross-reference to the place where `disassemble' is 
>described, so that the reader could find out what arguments does this 
>command accept.
>
>  
>
Done.

* printcmd.c (maintenance_info_lines): created
              (_initialize_printcmd): add command

* doc/gdb.textinfo: add documentation for 'maint info lines'



[-- Attachment #2: diff --]
[-- Type: application/x-java-applet, Size: 3808 bytes --]

Re: [RFA] new command: 'maintenance info lines'

[Eli Zaretskii]

On Mon, 23 Sep 2002, Josef Ezra wrote:

> >Thanks.  Please add a cross-reference to the place where `disassemble' is 
> >described, so that the reader could find out what arguments does this 
> >command accept.
> >
> Done.
> 
> * printcmd.c (maintenance_info_lines): created
>               (_initialize_printcmd): add command
> 
> * doc/gdb.textinfo: add documentation for 'maint info lines'

The documentation patch is approved.  Thanks!

Re: [RFA] new command: 'maintenance info lines'

[Fernando Nasser]

Josef,

The maintenance commands are to be used to debug (or test) GDB only.
We could say you'd be dumping the line table but that is hardly what is being 
done and we don't have a real need for that anyway.

As Andrew told you on June 13, 2002:

http://sources.redhat.com/ml/gdb-patches/2002-06/msg00222.html

We already have a mechanism for obtaining that information in GDB.
The MI interface is what you should be using to obtain data.
And you don't even need to create the mixed source+assembler output as that is 
already done for you.

If you really want to use a CLI command, you need to add a set/show variable to 
request that the source lines are included in the 'disassemble' command output.
The newer disassembler code that handles mixed output is still in the MI 
subdirectory (and in an older form in the gdbtk subdir) but it is intended to 
replace the one in printcmd.c.  It shouldn't be too difficult and you can always 
ask if you have any doubts.

Regards,
Fernando


Josef Ezra wrote:> Michael Snyder wrote:
> 
>> Josef Ezra wrote:
>>
>>> Michael Snyder wrote:
>>>
>>>> I like it as maybe a maintainer command (or even a user one, if
>>>> you think users might gain something from it.
>>>>
>>>> I don't like the name, though -- "info orientation" doesn't say
>>>> anything to me.  Maybe "info lines"?  Or, as a maintainer command,
>>>> "info sal"?
>>>>
>>>
>>> Following the line of 'maintenance info breakpoints / sections /
>>> sol-threads' commands, I'd like to suggest 'maintenance info lines' for
>>> this line-address dump.
>>
>>
>>
>> Works for me.
>>
>>
> 
> hi
> 
> It took a while to resolve the legal issues, so I'm re-committing ..
> 
> - jezra
> 
> * printcmd.c (maintenance_info_lines): created
>               (_initialize_printcmd): add command
> 
> * doc/gdb.textinfo: add documentation for 'maint info lines'
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: doc/gdb.texinfo
> ===================================================================
> RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
> retrieving revision 1.120
> diff -u -3 -r1.120 gdb.texinfo
> --- doc/gdb.texinfo	5 Sep 2002 12:13:08 -0000	1.120
> +++ doc/gdb.texinfo	5 Sep 2002 21:01:23 -0000
> @@ -4362,6 +4362,13 @@
>  can set @var{instruction-set} to either @code{intel} or @code{att}.
>  The default is @code{att}, the AT&T flavor used by default by Unix
>  assemblers for x86-based targets.
> +
> +@kindex maint info lines
> +@item maint info lines
> +This command takes same parameters as @code{disassemble}, but only 
> +dumps an @code{@var{address}:@var{line}} pairs.  Every pair means: ``from this 
> +@var{address} forward, the code was generated by that @var{line}''.  
> +
>  @end table
>  
>  
> Index: printcmd.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/printcmd.c,v
> retrieving revision 1.40
> diff -u -3 -r1.40 printcmd.c
> --- printcmd.c	11 Jul 2002 20:46:19 -0000	1.40
> +++ printcmd.c	5 Sep 2002 21:01:23 -0000
> @@ -2390,6 +2390,75 @@
>  }
>  \f
>  
> +/*
> +  Print range as 'Address:Line' pairs. This command might be usefull
> +  to associate sources and assembly commands. 
> +*/
> +
> +static void
> +maintenance_info_lines (char *arg, int from_tty)
> +{
> +  CORE_ADDR low, high;
> +  {
> +    char *name;
> +    CORE_ADDR pc, pc_masked;
> +    char *space_index;
> +    name = NULL;
> +    if (!arg)
> +      {
> +        if (!selected_frame)
> +          error ("No frame selected.\n");
> +
> +        pc = get_frame_pc (selected_frame);
> +        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
> +          error ("No function contains program counter for selected frame.\n");
> +
> +        low += FUNCTION_START_OFFSET;
> +      }
> +    else if (!(space_index = (char *) strchr (arg, ' ')))
> +      {
> +        /* One argument.  */
> +        pc = parse_and_eval_address (arg);
> +        if (find_pc_partial_function (pc, &name, &low, &high) == 0)
> +          error ("No function contains specified address.\n");
> +        low += FUNCTION_START_OFFSET;
> +      }
> +    else
> +      {
> +        /* Two arguments.  */
> +        *space_index = '\0';
> +        low = parse_and_eval_address (arg);
> +        high = parse_and_eval_address (space_index + 1);
> +      }
> +  }
> +  /* OK, we got the low-high range, what now? */
> +  {
> +    struct symtab *symtab ;
> +    struct linetable_entry *le ;
> +    int i, nitems ;
> +    symtab = find_pc_symtab (low ) ;
> +    if (symtab && symtab->linetable) 
> +      {
> +    
> +        le = symtab->linetable->item ;
> +        nitems = symtab->linetable->nitems ;
> +
> +                                /* skip to low */
> +        for (i = 0 ; 
> +             (i < nitems - 1) && (le[i + 1].pc < low) ; 
> +             i++ ) ;
> +
> +                                /* and print all the way to high */
> +        for (; (i < nitems -1) && (le[i].pc <= high); i++ )
> +          {
> +            if (le[i].pc   != le[i+1].pc   ) 
> +                                /* optimized line ? */
> +              printf_filtered ("0x%08x:%d\n", (unsigned) le[i].pc, le[i].line ) ;
> +          }
> +      }
> +  }
> +}
> +
>  void
>  _initialize_printcmd (void)
>  {
> @@ -2568,5 +2637,11 @@
>    examine_h_type = init_type (TYPE_CODE_INT, 2, 0, "examine_h_type", NULL);
>    examine_w_type = init_type (TYPE_CODE_INT, 4, 0, "examine_w_type", NULL);
>    examine_g_type = init_type (TYPE_CODE_INT, 8, 0, "examine_g_type", NULL);
> +  add_cmd ( "lines", class_maintenance, maintenance_info_lines,
> +            concat ("Dump a line-address table a specified section of memory.\n\
> +Default is the function surrounding the pc of the selected frame.\n\
> +With a single argument, the function surrounding that address is dumped.\n\
> +Two arguments are taken as a range of memory to dump.", NULL ), 
> +            &maintenanceinfolist) ; 
>  
>  }



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] new command: 'maintenance info lines'

[Josef Ezra]

Fernando Nasser wrote:

> The maintenance commands are to be used to debug (or test) GDB only.
> We could say you'd be dumping the line table but that is hardly what 
> is being done and we don't have a real need for that anyway.
>
well, WE have a real need for this command (is there a wrong way to use 
gdb?). but we sure don't need it to maintain gdb.

> If you really want to use a CLI command, you need to add a set/show 
> variable to request that the source lines are included in the 
> 'disassemble' command output. 

do you mean something like:

(gdb) set  disassem dump-source-or-something 1
(gdb) disassemble main
Dump of assembler code for function main:
    Line ../gdb/main.c:757
0x50ce4 <main>: save  %sp, -120, %sp
0x50ce8 <main+4>:       std  %i0, [ %fp + -24 ]
0x50cec <main+8>:       sethi  %hi(0x50000), %o0
0x50cf0 <main+12>:      or  %o0, 0x16c, %o0     ! 0x5016c <captured_main>
0x50cf4 <main+16>:      sethi  %hi(0x2a7c00), %o2
    Line ../gdb/main.c:759
0x50cf8 <main+20>:      add  %fp, -24, %o1
0x50cfc <main+24>:      or  %o2, 0x3c0, %o2
0x50d00 <main+28>:      call  0xb2374 <catch_errors>
0x50d04 <main+32>:      mov  6, %o3
    Line ../gdb/main.c:775
0x50d08 <main+36>:      ret
0x50d0c <main+40>:      restore  %g0, 0, %o0
End of assembler dump.

that would be a great solution for our needs. how about setting the 
dump-source to 1 to show line location, and 2 to try presenting the 
actual source lines (like mixed list and disassemble)

> The newer disassembler code that handles mixed output is still in the 
> MI subdirectory (and in an older form in the gdbtk subdir) but it is 
> intended to replace the one in printcmd.c.  It shouldn't be too 
> difficult and you can always ask if you have any doubts. 

?? please explain

thanks - jezra

Re: [RFA] new command: 'maintenance info lines'

[Fernando Nasser]

Josef Ezra wrote:
> Fernando Nasser wrote:
> 
>> The maintenance commands are to be used to debug (or test) GDB only.
>> We could say you'd be dumping the line table but that is hardly what 
>> is being done and we don't have a real need for that anyway.
>>
> well, WE have a real need for this command 

That is the problem.  We can't go and add things to GDB to the use of each 
individual need.  That is why the MI was added so that any tool developer can 
use that to talk to GDB.

> (is there a wrong way to use 
> gdb?). 
> 

Definitively parsing CLI output is one.

>> If you really want to use a CLI command, you need to add a set/show 
>> variable to request that the source lines are included in the 
>> 'disassemble' command output. 
> 
> 
> do you mean something like:
> 
> (gdb) set  disassem dump-source-or-something 1
> (gdb) disassemble main
> Dump of assembler code for function main:
>    Line ../gdb/main.c:757
> 0x50ce4 <main>: save  %sp, -120, %sp
> 0x50ce8 <main+4>:       std  %i0, [ %fp + -24 ]
> 0x50cec <main+8>:       sethi  %hi(0x50000), %o0
> 0x50cf0 <main+12>:      or  %o0, 0x16c, %o0     ! 0x5016c <captured_main>
> 0x50cf4 <main+16>:      sethi  %hi(0x2a7c00), %o2
>    Line ../gdb/main.c:759
> 0x50cf8 <main+20>:      add  %fp, -24, %o1
> 0x50cfc <main+24>:      or  %o2, 0x3c0, %o2
> 0x50d00 <main+28>:      call  0xb2374 <catch_errors>
> 0x50d04 <main+32>:      mov  6, %o3
>    Line ../gdb/main.c:775
> 0x50d08 <main+36>:      ret
> 0x50d0c <main+40>:      restore  %g0, 0, %o0
> End of assembler dump.
> 

Exactly, but the source line itself (if available) will be displayed as well.

> that would be a great solution for our needs. how about setting the 
> dump-source to 1 to show line location, and 2 to try presenting the 
> actual source lines (like mixed list and disassemble)
> 

Actually, I was thinking of

set/show mixed-disassembly on/off

There is no point in not showing the source lines themselves on the CLI output. 
  Tools using GDB as the backend may want to manipulate the source files 
themselves, and that is why the MI output only have the line number (not the 
content of the source file line).


>> The newer disassembler code that handles mixed output is still in the 
>> MI subdirectory (and in an older form in the gdbtk subdir) but it is 
>> intended to replace the one in printcmd.c.  It shouldn't be too 
>> difficult and you can always ask if you have any doubts. 
> 
> 
> ?? please explain
> 

Sure.  The newest code for disassembly is in the file mi/mi-cmd-disas.c.
This is supposed to replace the old one in printcmd.c which was not capable of 
mixed-mode disassembly.  Once this code is in the libgdb proper, all interfaces 
(CLI, MI and gdbtk) will use this same code.

Maybe it helps if you know the story:
.the code in printcmd.c came first
.it was improved in gdbtk land to allow mixed-mode disassembly
.it was copied with small changes to MI land
.the code in MI was improved to be more modular (and facilitate splitting the UI 
and core parts).
.MISSING: Replace the old code and use the new one (from mi-cmd-disas.c) and use 
it everywhere, getting rid of all the other versions.


We are slowly doing this.  It was not a priority as it is already working on the 
MI and having mixed-mode disassembly in the CLI is just an enhancement no one 
has ever asked for (although I think it would be nice).  We are doing it more 
like a clean-up.

I will take a look and see if I can find time and do it.  Or do you want to give 
it a try yourself?

Regards,
Fernando


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] new command: 'maintenance info lines'

[Andrew Cagney]

Just FYI,

I believe that GDB is getting a new interpreter command vis:

(gdb) interpreter mi -data-disassemble ....
<mi output>
(gdb)

(assuming I've got the syntax right) this will make it possible for an 
existing CLI based front end to incrementally convert to the better 
supported MI front end.

Andrew