C++ Overload Resolution

This is a summary of the research I have been doing on the subject. This 
is probably going to be a long email, but I am doing it mainly as an 
exercise to ensure that I record all I understood from the spec and 
understand gdb to do.

This is a summary of Chapter 4, section 13.3, and section 14.5.5.2 of 
the C++ spec and some googling, guessing and compiling.

I would appreciate your input, questions, and corrections.

When
====

Overload resolution takes place when:

1) invoking a function by name:
   - a.foo()
   - ap->foo()
   - foo()

2) An invocation of the function call operator '()'
   - class A{
       int operator (int) {}
       int operator (char){}
     }
     A a;
     a(1)

3) Invoking a pointer-to-function conversion function.
   I don't know what that is. I guessed this:

Re: gdbstub initial code, v12

On 09/30, Oleg Nesterov wrote:
>
> Right now $G doesn't change FPU registers.

It turns out, $G can't even set the REGSET_GENERAL reg correctly.
I noticed this only because the tracee sometimes dies during the
single-stepping inside the dynamic linker. Indeed, $G passes the
wrong fs_index==0 to genregs_set().

> Next: watchpoints.

While trying to understand what does this mean, I hit another bug
in ugdb. A multithreaded tracee can "hang" if gdb simulates
watchpoints with single-steps + mem-fetch/compare. Still can't
understand why this happens, this should be resolved. This never
happens if the tracee is single-threaded.

Oleg.

Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12)

On Tuesday 05 October 2010 18:27:29, Oleg Nesterov wrote:

> The more or less "typical" transcript is:
> 
> 	[... snip ...]
> 	=> s

This is already wrong.

"The stub must support  <at> samp{vCont} if it reports support for
multiprocess extensions ( <at> pxref{multiprocess extensions})."

The stub must also support vCont for non-stop, though I'll give you
that it doesn't appear to be mentioned in the manual, and that
gdb could be more noisy about this.

Look at remote.c:remote_resume, and you'll see that gdb does not
wait for the "OK" after 'c'/'s'/'S'/'C' in non-stop mode.
You're getting "lucky", because when gdb processes the OK you're
sending it, gdb is interpreting that as an 'O' stop reply, but
since 'K' is an uneven number of characters, remote_console_output
happens to just bail out silently.

Now, given this, I won't be surprised if you're seeing races
with ->s, <-OK, ->vCont sequences, as GDB may well be thinking
that the "OK" is a reply to the vCont.

> So, I strongly believe gdb is buggy and should be fixed.

Fix your stub to implement vCont;s/c(/S/C).

Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12)

On Tuesday 05 October 2010 19:30:38, Pedro Alves wrote:
> Now, given this, I won't be surprised if you're seeing races
> with ->s, <-OK, ->vCont sequences, as GDB may well be thinking
> that the "OK" is a reply to the vCont.
> 

I meant ->s, <-OK, ->vStopped sequences.

--

-- 
Pedro Alves

Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12)

On Wednesday 06 October 2010 18:19:53, Oleg Nesterov wrote:
> On 10/05, Pedro Alves wrote:
> > "The stub must support  <at> samp{vCont} if it reports support for
> > multiprocess extensions ( <at> pxref{multiprocess extensions})."
> 
> Cough. Previously I was told here (on archer@...) that
> Hc + s/c is enough and I shouldn't worry about vCont;s/c ;)

vCont was introduced because with only 'Hc', 's' and 'c', there's
no way to distinguish "step a thread and resume all others" vs "step
a thread and leave others stopped" (scheduler-locking, in gdb lingo).
This was added way before non-stop was added, back in 2002/2003,
I believe.  vCont;t was added much later, when non-stop was
introduced.

> > The stub must also support vCont for non-stop, though I'll give you
> > that it doesn't appear to be mentioned in the manual,
> 
> Yes, the manual doesn't explain this. Quite contrary, the decsription
> of 'vCont?' definitely looks as if the stub is not obliged to implement
> all vCont commands.
> 
> And, if the stub must support vCont for non-stop, then why gdb
> doesn't complain after 'vCont?' but falls back to '$s' ?

Because nobody took the trouble to made it complain.  As I said,
I'll give you that gdb could be noisier about that...

> > Look at remote.c:remote_resume, and you'll see that gdb does not
> > wait for the "OK" after 'c'/'s'/'S'/'C' in non-stop mode.

gdbstub initial code, v13

Changes:

	- misc fixes in readmem, pb, etc

	- remove the obsolete getregs code

	- $G remains buggy, will be fixed later.
	  gdb seems to never use it as far as $P works

	- full vCont support.

	  Well, this was easy, except even after 3 hours
	  of debugging I can't understand why this change
	  breaks the stepping over pthread_create :/
	  Otherwise it seems to work.
	  Will continue tomorrow.

Next: software watchpoints.

Oleg.

#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/utrace.h>
#include <linux/kernel.h>
#include <linux/poll.h>
#include <linux/mm.h>
#include <linux/regset.h>

Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12)

On Thursday 07 October 2010 23:59:22, Oleg Nesterov wrote:
> Hmm. Not sure I understand this... gdb could issue a series of Hc+c
> after s to do "step a thread and resume all others".
> 
> But this doesn't matter. Obviously vCont is better and more handy.

Not in all-stop mode.  GDB can not send any other command to the
stub until the stub returns a stop reply to the first 's'.  Remember,
there's no vStopped+notifications in the all-stop mode protocol.

--

-- 
Pedro Alves

Re: BUG: gdb && notification packets (Was: gdbstub initial code, v12)

On 10/08, Pedro Alves wrote:
>
> On Thursday 07 October 2010 23:59:22, Oleg Nesterov wrote:
> > Hmm. Not sure I understand this... gdb could issue a series of Hc+c
> > after s to do "step a thread and resume all others".
> >
> > But this doesn't matter. Obviously vCont is better and more handy.
>
> Not in all-stop mode.

Ah indeed. I missed you mentioned "This was added way before non-stop"
later.

Oleg.

BUG? gdb, software watchpoints && multithreading

I am trying to understand how ugdb can implement software watchpoints.
I am looking at what gdb does, and I am a bit confused.

Trivial test-case:

	#include <stdio.h>
	#include <unistd.h>
	#include <pthread.h>

	struct {
		long v;
		char pad[256];
	} VAR;

	void *tfunc(void *arg)
	{
		for (;;)
			;
	}

	int main(void)
	{
		pthread_t thr;

		printf("pid: %d\n", getpid());

		pthread_create(&thr, NULL, tfunc, NULL);

		for (;;)
			VAR.v++;

Re: gdbstub initial code, v8 && ptrace

> But. Suppose we have to attached engines. The first engine gets
> UTRACE_SIGNAL_REPORT and returns "UTRACE_STOP | UTRACE_SIGNAL_IGN".

Right, that's what it would do.  I see, you're saying that the
report.result passed on to the next engine would appear like it had
been a real signal that the previous engine decided to ignore (or
whose sa_handler==SIG_IGN or default action was to ignore).  Hmm.

Well, it's also distinguished by having orig_ka==NULL in the callback.
Any real signal has a non-null orig_ka argument.

> or yes, it returns UTRACE_SIGNAL_DELIVER after gdb does "signal XX".
> 
> Now. The second engine gets UTRACE_SIGNAL_DELIVER or UTRACE_SIGNAL_IGN,
> not UTRACE_SIGNAL_REPORT.

At least in the UTRACE_SIGNAL_DELIVER case, that's really the true
thing for it to see.  The previous engine decided to do a signal
delivery (as directed by return_ka), so the next engine needs to see
this to know what the prevailing state of play is now.

> That is why ugdb_signal_report(UTRACE_SIGNAL_REPORT) tries to return
> UTRACE_STOP | utrace_signal_action(action) to not change report->result
> (passed to the next tracee) inside the reporting loop.

Well, it *can* do that.  If UTRACE_SIGNAL_REPORT (or anything else
random) is the ultimate report.result from the whole callback loop, we
treat it just like UTRACE_SIGNAL_IGN.

> The worst case is UTRACE_SIGNAL_HANDLER. Single-stepping should know