Hi,

On 09/17/2014 04:53 AM, Mihail-Marian Nistor wrote:
> We need to cover the following test case: the user wants to do an action
> only for the function that was defined into a selected file name.
> An example: the user wants to put a breakpoint only for functions "func"
> that was defined in the file name "file.s"
>      e.i. of gdb command line: b file.s:func
> Due to the limitation that the GAS doesn't generate debug info for
> functions/symbols, we cannot find the function information if we look only
> in file symbtabs that was collected by using the file name specified by
> the user.
> We need to look into a global default symtab if we want to find minimal
> information about functions that were written in the ASM file.
> And after that, we need to select only functions that were defined into
> the file name specified by the user.

Thanks for the detailed explanation (and *especially* the test case) -- 
those have helped me immensely to understand the problem.

I spent some time looking into this patch/problem, and I am not quite 
sure the proposed solution is the right way to attack this.

My current feeling on this is: the behavior of the linespec parser (and 
coordinating routines) should not behave necessarily any different 
between the two use cases "break foo.c:func" and "break foo.s:func". 
Yet, the former works and the later does not.

So I did some digging. Maybe you have already discounted the approach I 
am going to suggest -- if so, I would be very interested in hearing 
about it.

When a user specifies a C/C++/Ada/Java/Asm/whatever filename, the 
linespec parser starts by building a list of file symtabs for the 
specified files.

All subsequent symbol searches are limited to results in those 
files/symtabs.

The problem here is that, as you point out, gas does not emit any symbol 
information for the .s file. Thus, we have a symtab for the file ("info 
sources" shows the file), but it contains no symbols.

When find_linespec_symbols is called in linespec_parse_basic, it calls 
find_function_symbols, which uses add_matching_symbols_to_info to 
collect all matching symbols.

That function does [pardon any mangled formatting]:

   for (ix = 0; VEC_iterate (symtab_ptr, info->file_symtabs, ix, elt); ++ix)
     {
       if (elt == NULL)
	{
	  iterate_over_all_matching_symtabs (info->state, name, VAR_DOMAIN,
					     collect_symbols, info,
					     pspace, 1);
	  search_minsyms_for_name (info, name, pspace);
	}
       else if (pspace == NULL || pspace == SYMTAB_PSPACE (elt))
	{
	  /* Program spaces that are executing startup should have
	     been filtered out earlier.  */
	  gdb_assert (!SYMTAB_PSPACE (elt)->executing_startup);
	  set_current_program_space (SYMTAB_PSPACE (elt));
	  iterate_over_file_blocks (elt, name, VAR_DOMAIN,
				    collect_symbols, info);
	}
     }

This iterates over the symtabs. In the failing use case, ELT is non-NULL 
(points to the symtab for the .s file), so it calls 
iterate_over_file_blocks. Herein is where the problem exists: it is 
assumed that if NAME exists, it must exist in the given symtab -- a 
reasonable assumption for "normal" (non-asm) cases. It never searches 
minimal symbols (or in the global default symtab).

This is where I think where the fix should start. While attempting to 
convince myself that approach is both appropriate and "correct," I've 
actually written a version of your patch which does this.

It is important to note that iterating over minsyms is fairly expensive, 
so in my patch, I've opted to only search minimal symbols for NAME if 
the symtab's language is language_asm and iterate_over_file_blocks 
returns no symbols. That should, hopefully, mitigate any performance 
impact this might have.

This is especially exasperated by the need to map the address of the 
minimal symbol back to its symtab. You'll see this (expensive) added 
complexity in add_minsym.

When all is said and done, though, when find_linespec_symbols returns, 
it will have collated the appropriate symbol from the .s file -- exactly 
the same way it would have if one had typed "break file.c:func".

What do you think about this? Does this fail on any use cases you have?

As for the test case, I would very much like to see this important 
functionality tested on every platform. I haven't tried it yet myself, 
but I see that some other tests in our test suite use some minimal 
assembler program which (presumably) runs on nearly every configuration. 
See, for example, gdb.dwarf2/dw2-anonymous-func.exp.
Your test example is simple enough that it should be fairly trivial to 
fixup.

In any case, I would move the test from gdb.arch to gdb.linespec, 
collecting it together with its linespec-specific test brethren.

Keith