[using-directive] Regression against FSF GDB

[using-directive] Regression against FSF GDB

[Jan Kratochvil]

Hi Sami,

I have noticed this regression during the demo.  `print x' works in cases
where it should not.

Current archer-swagiaal-using-directive:
$ ./gdb -nx -q -ex start -ex 'p x' -ex q /tmp/alias
Temporary breakpoint 1 at 0x400560: file alias.C, line 10.
Starting program: /tmp/alias 

Temporary breakpoint 1, main () at alias.C:10
10	  return B::x;
$1 = 9

Current FSF GDB HEAD (+also F10):
$ .../gdb -nx -q -ex start -ex 'p x' -ex q /tmp/alias
Temporary breakpoint 1 at 0x400560: file alias.C, line 10.
Starting program: /tmp/alias 

Temporary breakpoint 1, main () at alias.C:10
10	  return B::x;
No symbol "x" in current context.
The program is running.  Quit anyway (and kill it)? (y or n) y

$ cat /tmp/alias.C
namespace A
{
  int x = 9;
}

namespace B=A;
int
main (void)
{
  return B::x;
}

It can be verified by gcc-c++-4.3.2-7 the reference to bare `x' is not valid:
/tmp/alias2.C: In function ‘int main()’:
/tmp/alias2.C:10: error: ‘x’ was not declared in this scope


Thanks for a fix,
Jan

Re: [using-directive] Regression against FSF GDB

[Sami Wagiaalla]

Jan Kratochvil wrote:
> Hi Sami,
> 
> I have noticed this regression during the demo.  `print x' works in cases
> where it should not.
> 

Yeah I noticed that too. Thanks Jan.

Incidentally I have also looked at this:

namespace A{
  int x;
}

namespace B{
  int x;
}

int main(){
  using namespace A;
  x; // This is okay [1]
  using namespace B;
  x; // This is illegal according to gcc [2]
}

The debug info is there and we have a choice of how to handle this in
gdb. [1] can be handled by checking the current line number with the
line number of the import that way we wont print B::x. Since [2] is
illegal we can do whatever we want in gdb, print the first x we find,
raise an error or ask the user to choose.

Sami

Re: [using-directive] Regression against FSF GDB

[Jan Kratochvil]

On Wed, 28 Jan 2009 22:26:44 +0100, Sami Wagiaalla wrote:
> Incidentally I have also looked at this:
> 
> namespace A{
>   int x;
> }
> 
> namespace B{
>   int x;
> }
> 
> int main(){
>   using namespace A;
>   x; // This is okay [1]
>   using namespace B;
>   x; // This is illegal according to gcc [2]
> }
> 
> The debug info is there and we have a choice of how to handle this in
> gdb. [1] can be handled by checking the current line number with the
> line number of the import that way we wont print B::x. Since [2] is
> illegal we can do whatever we want in gdb,

gcc-c++-4.3.2-7:
/tmp/illegal.C:13: error: reference to ‘x’ is ambiguous
/tmp/illegal.C:6: error: candidates are: int B::x
/tmp/illegal.C:2: error:                 int A::x

I do not agree there is any choice.  Primarily Archer should follow how would a
C++ compiler behave.  As the described source file can never produce a valid
binary output GDB should consider such found DWARF info as invalid and use:
  complaint (&symfile_complaints, _("..."));

> raise an error or ask the user to choose.

And yes, even error()-out if the user requests to reference such variable.


But if I understand it correctly such case may never happen in practice as C++
will never produce such binary so I doubt it is a serious concern.


Regards,
Jan