This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] ada testsuite: False FAILs with gcc debug info


> with installed and matching debug infos there flip some gdb.ada/ testsuite
> results PASS->FAIL:

Yeah - I wasn't expecting anyone to run the testsuite using a runtime
that has debugging info.  It introduces other issues as well (we worked
around some of these issues for the sake of people working on the
compiler). It's not easy for you to flip runtimes, so we can try
accomodating...

Just a thought: Perhaps it might be easier to flip runtimes if you
provide the runtime with debug info as a second runtime.  There is
a way to do this, and then the user controls which one he wants using
--RTS=<rts-name> (only when the default one is not the one he wants).

>  (gdb) print String_Var (1 .. 3) = "Hel"
> -$1 = true
> -(gdb) PASS: gdb.ada/str_ref_cmp.exp: print String_Var (1 .. 3) = "Hel"
> +$1 = false
> +(gdb) FAIL: gdb.ada/str_ref_cmp.exp: print String_Var (1 .. 3) = "Hel"
> as even just
> (gdb) print "a"="a"
> starts giving `false' with debug info installed, the BINOP_EQUAL
> operator resolves to: ada__strings__maps__Oeq (Ada.Strings.Maps) as
> its type matches in ada_resolve_function.  I do not understand the Ada
> scoping to fix it, filed PR for KFAIL.

This is incorrect, but I cannot reproduce (we should be able to get
the same behavior by recompiling the program with "-f -a", which tells
gnatmake to recompile everything, including runtime files).

In this case, the lookup is "wild", because the entity name is not
qualified using the package name.  Regardless of that, the scoping
rules we use to match is:
  - If there is a local symbol, use that and disregard any global
    symbol that might have matched otherwise;
  - If no match, then we move to file-static, I think;
  - And finally, we look for globals;

The match is incorrect as far as I can tell, because the only "="
function defined in this package is the one for type Character_Set:

   function "="   (Left, Right : Character_Set) return Boolean;

And type Character_Set does not match type String:

   type Character_Set_Internal is array (Character) of Boolean;
   pragma Pack (Character_Set_Internal);
   type Character_Set is new Character_Set_Internal;

Type string is implicitly defined as:

   type String is array (Positive range <>) of Character;
   pragma Pack (String);

I think the debugging info must be incorrect.

That being said, we noticed a side-effect of this kind a while ago,
except I can't find it in my notes anymore. It was valid matching
at the time, except that the user-define "=" did not have the usual
semantics, and thus was yielding surprising results.

> gdb/testsuite/
> 2011-03-27  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* gdb.ada/arrayparam.exp (print first after function call): Use
> 	explicit package name.  Add a comment
> 	(print lasta after function call): Rename ...
> 	(print last after function call): ... it and use explicit package
> 	name.
> 	(print length after function call): Use explicit package name.
> 	* gdb.ada/str_ref_cmp.exp (operator = works for strings): New test.
> 	* gdb.ada/sym_print_name.exp: Change `i' to `integervar'.
> 	(multiple matches for symbol i): Rename ...
> 	(multiple matches for symbol integervar): ... it.
> 	* gdb.ada/sym_print_name/foo.adb (Foo): Change `I' to `IntegerVar'.
> 	* gdb.ada/sym_print_name/pck.ads (Pck): Likewise.

This is OK.

Just one minor comment: `IntegerVar' is not very Ada-ish. Normally,
one would use `Integer_Var' instead.  However, thinking about it,
I think it's good, because it reduces further the chances of this
entity name being used in the compiler runtime, thus causing an
extra unexpected match. So, let's keep it that way.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]