[PATCH/RFC] faster language identification

[PATCH/RFC] faster language identification

[Elias Athanasopoulos]

Hi all,

DWARFx encodes the language. In such a case, I think it is more 
reliable to get the language from the object, instead of looking at the 
source files' extensions.

Comments?

Elias

ChangeLog

2002-11-07  Elias Athanasopoulos  <eathan@otenet.gr>

	* symfile.c (symbol_file_add): Read the first partial symbol
	table.
	(symbol_file_add_main_1): Store the return value of symbol_file_add
	to objfile. Check if we have already identify the language and set
	it, otherwise call set_initial_language.
	
===================================================================
RCS file: /home/anteater/bucvs/src/gdb/symfile.c,v
retrieving revision 1.1
diff -u -p -r1.1 /home/anteater/bucvs/src/gdb/symfile.c
--- /home/anteater/bucvs/src/gdb/symfile.c	2002/11/07 20:36:37	1.1
+++ /home/anteater/bucvs/src/gdb/symfile.c	2002/11/07 20:36:59
@@ -877,7 +877,13 @@ symbol_file_add (char *name, int from_tt
 	}
       syms_from_objfile (objfile, addrs, mainline, from_tty);
     }
-
+  
+  /* Read the first partial symbol table.  This may help us to identify
+     the language of the object, faster and more reliable, if the object
+     contains DWARF information. */
+   
+  psymtab_to_symtab (objfile->psymtabs); 
+      
   /* We now have at least a partial symbol table.  Check to see if the
      user requested that all symbols be read on initial access via either
      the gdb startup command line or on a per symbol file basis.  Expand
@@ -939,7 +945,10 @@ symbol_file_add_main (char *args, int fr
 static void
 symbol_file_add_main_1 (char *args, int from_tty, int flags)
 {
-  symbol_file_add (args, from_tty, NULL, 1, flags);
+  struct objfile *objfile;
+  enum language lang = language_unknown;
+  
+  objfile = symbol_file_add (args, from_tty, NULL, 1, flags);
 
 #ifdef HPUXHPPA
   RESET_HP_UX_GLOBALS ();
@@ -949,7 +958,17 @@ symbol_file_add_main_1 (char *args, int 
      what is frameless.  */
   reinit_frame_cache ();
 
-  set_initial_language ();
+  /* DWARF supports language encoding along with the debugging 
+     information.  If we have a DWARF object, we might have 
+     already grabbed the language.  Read the comment before 
+     set_initial_language().  */
+  if (objfile->psymtabs->symtab != NULL)
+    lang = objfile->psymtabs->symtab->language;
+  
+  if (lang != language_unknown)
+    set_language (lang);
+  else
+    set_initial_language ();
 }
 
 void

Re: [PATCH/RFC] faster language identification

[Daniel Jacobowitz]

On Thu, Nov 07, 2002 at 10:46:22PM +0200, Elias Athanasopoulos wrote:
> Hi all,
> 
> DWARFx encodes the language. In such a case, I think it is more 
> reliable to get the language from the object, instead of looking at the 
> source files' extensions.
> 
> Comments?

Please don't.  See:

/* Set the initial language.

   A better solution would be to record the language in the psymtab when reading
   partial symbols, and then use it (if known) to set the language.  This would
   be a win for formats that encode the language in an easily discoverable place,
   such as DWARF.  For stabs, we can jump through hoops looking for specially
   named symbols or try to intuit the language from the specific type of stabs
   we find, but we can't do that until later when we read in full symbols.
   FIXME.  */

static void
set_initial_language (void)

Either that or there should be a psymtab_language() method somewhere.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH/RFC] faster language identification

[Elias Athanasopoulos]

Hi Daniel,

On Thu, Nov 07, 2002 at 02:34:09PM -0500, Daniel Jacobowitz wrote:
> Please don't.  See:
> 
> /* Set the initial language.
> 
>    A better solution would be to record the language in the psymtab when reading
>    partial symbols, and then use it (if known) to set the language.  This would
>    be a win for formats that encode the language in an easily discoverable place,
>    such as DWARF.  For stabs, we can jump through hoops looking for specially
>    named symbols or try to intuit the language from the specific type of stabs
>    we find, but we can't do that until later when we read in full symbols.
>    FIXME.  */
> 
> static void
> set_initial_language (void)
> 
> Either that or there should be a psymtab_language() method somewhere.

Actually, this is what the patch does. :-) It sets the language according
to the information recorded in the psymtab (_if_ it is recorded, as it does with
DWARF).

Elias

Re: [PATCH/RFC] faster language identification

[Daniel Jacobowitz]

On Thu, Nov 07, 2002 at 11:03:21PM +0200, Elias Athanasopoulos wrote:
> Hi Daniel,
> 
> On Thu, Nov 07, 2002 at 02:34:09PM -0500, Daniel Jacobowitz wrote:
> > Please don't.  See:
> > 
> > /* Set the initial language.
> > 
> >    A better solution would be to record the language in the psymtab when reading
> >    partial symbols, and then use it (if known) to set the language.  This would
> >    be a win for formats that encode the language in an easily discoverable place,
> >    such as DWARF.  For stabs, we can jump through hoops looking for specially
> >    named symbols or try to intuit the language from the specific type of stabs
> >    we find, but we can't do that until later when we read in full symbols.
> >    FIXME.  */
> > 
> > static void
> > set_initial_language (void)
> > 
> > Either that or there should be a psymtab_language() method somewhere.
> 
> Actually, this is what the patch does. :-) It sets the language according
> to the information recorded in the psymtab (_if_ it is recorded, as it does with
> DWARF).

No, the patch converts the psymtab to a symtab and uses the language in
the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
expensive!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH/RFC] faster language identification

[Elias Athanasopoulos]

Hi Daniel,

On Thu, Nov 07, 2002 at 02:48:38PM -0500, Daniel Jacobowitz wrote:
> No, the patch converts the psymtab to a symtab and uses the language in
> the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
> expensive!

Ah right! My bad. :-(

Elias

Re: [PATCH/RFC] faster language identification

[Michael Snyder]

Elias Athanasopoulos wrote:
> 
> Hi Daniel,
> 
> On Thu, Nov 07, 2002 at 02:48:38PM -0500, Daniel Jacobowitz wrote:
> > No, the patch converts the psymtab to a symtab and uses the language in
> > the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
> > expensive!
> 
> Ah right! My bad. :-(

Perhaps the patch could be added to psymtab_to_symtab, 
so that it would not try to get the language until 
the symbols were going to be read anyway?

Re: [PATCH/RFC] faster language identification

[Elias Athanasopoulos]

Hi Michael,

On Thu, Nov 07, 2002 at 12:55:47PM -0800, Michael Snyder wrote:
> Elias Athanasopoulos wrote:
> > On Thu, Nov 07, 2002 at 02:48:38PM -0500, Daniel Jacobowitz wrote:
> > > No, the patch converts the psymtab to a symtab and uses the language in
> > > the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
> > > expensive!
> Perhaps the patch could be added to psymtab_to_symtab, 
> so that it would not try to get the language until 
> the symbols were going to be read anyway?

Yes, that may work, although I don't know exactly where gdb *really* needs
to set the language.

I was thinking of what Daniel proposed; a psymtab_language() function. But,
even in the DWARF case, consider this:

% gcc -Wa,-gdwarf2 bar.s foo.c -o foo

Now, the language should be set to 'asm'? This is what you'll get if you try
to parse the .debug_info section. Currently, gdb in the above case sets it
to 'c'.

Also, there is the case that you enable DWARF in both as and gcc, but I think
this shouldn't be allowed by gcc.

Elias

Re: [PATCH/RFC] faster language identification

[Daniel Jacobowitz]

On Sun, Nov 10, 2002 at 05:01:25PM +0200, Elias Athanasopoulos wrote:
> Hi Michael,
> 
> On Thu, Nov 07, 2002 at 12:55:47PM -0800, Michael Snyder wrote:
> > Elias Athanasopoulos wrote:
> > > On Thu, Nov 07, 2002 at 02:48:38PM -0500, Daniel Jacobowitz wrote:
> > > > No, the patch converts the psymtab to a symtab and uses the language in
> > > > the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
> > > > expensive!
> > Perhaps the patch could be added to psymtab_to_symtab, 
> > so that it would not try to get the language until 
> > the symbols were going to be read anyway?
> 
> Yes, that may work, although I don't know exactly where gdb *really* needs
> to set the language.
> 
> I was thinking of what Daniel proposed; a psymtab_language() function. But,
> even in the DWARF case, consider this:
> 
> % gcc -Wa,-gdwarf2 bar.s foo.c -o foo
> 
> Now, the language should be set to 'asm'? This is what you'll get if you try
> to parse the .debug_info section. Currently, gdb in the above case sets it
> to 'c'.
> 
> Also, there is the case that you enable DWARF in both as and gcc, but I think
> this shouldn't be allowed by gcc.

Well, it _should_ be asm.  We don't have line number information for
the .c source.  IMHO.

(Also IMHO, the user just shouldn't do that...)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH/RFC] faster language identification

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Sun, Nov 10, 2002 at 05:01:25PM +0200, Elias Athanasopoulos wrote:
> > Hi Michael,
> > 
> > On Thu, Nov 07, 2002 at 12:55:47PM -0800, Michael Snyder wrote:
> > > Elias Athanasopoulos wrote:
> > > > On Thu, Nov 07, 2002 at 02:48:38PM -0500, Daniel Jacobowitz wrote:
> > > > > No, the patch converts the psymtab to a symtab and uses the language in
> > > > > the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
> > > > > expensive!
> > > Perhaps the patch could be added to psymtab_to_symtab, 
> > > so that it would not try to get the language until 
> > > the symbols were going to be read anyway?
> > 
> > Yes, that may work, although I don't know exactly where gdb *really* needs
> > to set the language.
> > 
> > I was thinking of what Daniel proposed; a psymtab_language() function. But,
> > even in the DWARF case, consider this:
> > 
> > % gcc -Wa,-gdwarf2 bar.s foo.c -o foo
> > 
> > Now, the language should be set to 'asm'? This is what you'll get if you try
> > to parse the .debug_info section. Currently, gdb in the above case sets it
> > to 'c'.
> > 
> > Also, there is the case that you enable DWARF in both as and gcc, but I think
> > this shouldn't be allowed by gcc.
> 
> Well, it _should_ be asm.  We don't have line number information for
> the .c source.  IMHO.
> 
> (Also IMHO, the user just shouldn't do that...)

Shouldn't do what?  Compile assembly with debug info?  Link object
modules with a mix of debuggingness?  I don't see what's wrong...

The right behavior here, it seems to me, depends on which module
contains 'main'.  If that module has debug info, we should use that to
choose the initial language; otherwise, we can guess from the source
filename.  Even .c files compiled without debugging info have a .file
directive in the assembly code, which turns into an STT_FILE linker
symbol.

Re: [PATCH/RFC] faster language identification

[Daniel Jacobowitz]

On Wed, Nov 13, 2002 at 12:45:50PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Sun, Nov 10, 2002 at 05:01:25PM +0200, Elias Athanasopoulos wrote:
> > > Hi Michael,
> > > 
> > > On Thu, Nov 07, 2002 at 12:55:47PM -0800, Michael Snyder wrote:
> > > > Elias Athanasopoulos wrote:
> > > > > On Thu, Nov 07, 2002 at 02:48:38PM -0500, Daniel Jacobowitz wrote:
> > > > > > No, the patch converts the psymtab to a symtab and uses the language in
> > > > > > the symtab.  That's what I want you NOT to do.  psymtab_to_symtab is
> > > > > > expensive!
> > > > Perhaps the patch could be added to psymtab_to_symtab, 
> > > > so that it would not try to get the language until 
> > > > the symbols were going to be read anyway?
> > > 
> > > Yes, that may work, although I don't know exactly where gdb *really* needs
> > > to set the language.
> > > 
> > > I was thinking of what Daniel proposed; a psymtab_language() function. But,
> > > even in the DWARF case, consider this:
> > > 
> > > % gcc -Wa,-gdwarf2 bar.s foo.c -o foo
> > > 
> > > Now, the language should be set to 'asm'? This is what you'll get if you try
> > > to parse the .debug_info section. Currently, gdb in the above case sets it
> > > to 'c'.
> > > 
> > > Also, there is the case that you enable DWARF in both as and gcc, but I think
> > > this shouldn't be allowed by gcc.
> > 
> > Well, it _should_ be asm.  We don't have line number information for
> > the .c source.  IMHO.
> > 
> > (Also IMHO, the user just shouldn't do that...)
> 
> Shouldn't do what?  Compile assembly with debug info?  Link object
> modules with a mix of debuggingness?  I don't see what's wrong...

No, compile C with assembly debug info, which that command line also
does.  That's the one that'll confuse us.

> The right behavior here, it seems to me, depends on which module
> contains 'main'.  If that module has debug info, we should use that to
> choose the initial language; otherwise, we can guess from the source
> filename.  Even .c files compiled without debugging info have a .file
> directive in the assembly code, which turns into an STT_FILE linker
> symbol.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH/RFC] faster language identification

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> > > > I was thinking of what Daniel proposed; a psymtab_language() function. But,
> > > > even in the DWARF case, consider this:
> > > > 
> > > > % gcc -Wa,-gdwarf2 bar.s foo.c -o foo
> > > > 
> > > > Now, the language should be set to 'asm'? This is what you'll get if you try
> > > > to parse the .debug_info section. Currently, gdb in the above case sets it
> > > > to 'c'.
> > > > 
> > > > Also, there is the case that you enable DWARF in both as and gcc, but I think
> > > > this shouldn't be allowed by gcc.
> > > 
> > > Well, it _should_ be asm.  We don't have line number information for
> > > the .c source.  IMHO.
> > > 
> > > (Also IMHO, the user just shouldn't do that...)
> > 
> > Shouldn't do what?  Compile assembly with debug info?  Link object
> > modules with a mix of debuggingness?  I don't see what's wrong...
> 
> No, compile C with assembly debug info, which that command line also
> does.  That's the one that'll confuse us.

Ooooh.  I see.  Yep.