Re: [RFC] Remove last occurences of target_{insert/remove}_watchpoint

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 06 May 2009 19:35:42, Joel Brobecker wrote:
> Yeah, I have roughly the same number of hits for that one.
> That leaves another thousand of so errors. As far as I can tell,
> they are made of several different symptoms: ~100 internal-errors,
> about a 100 are caused by the fact that we failed to run the program
> or ran the program to completion, etc etc etc.

I think that those other problems may be related to the issue
I mentioned on IRC the other day.  The fact that the procfs.c
code that sets a breakpoint at __dbx_link during the startup phase
is broken.  I'll paste it here for posterity.  :-)

- That breakpoint was set during the startup phase by catching
  syscall-exits during the startup phase, more precisely, during
  the phase that the inferior is ran through the dynamic linker in
  solib_create_inferior_hook -> irix_solib_create_inferior_hook.

  This was done by enabling PR_SYSEXIT syscall tracing in procfs_init_inferior,
  and disabling after fork_inferior returned.  Look for SYS_syssgi in
  procfs.c to see this. 

  This worked because many moons ago, at the time that code was
  written, fork_inferior used to call solib_create_inferior_hook before
  returning.

  http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/fork-child.c.diff?r1=1.28&r2=1.27.6.1&cvsroot=src&f=h

- Problem is, that now, solib_create_inferior is only called *after* all of this, in
  post_create_inferior.  So the wrapping to catch syscall-exits is being done
  at the wrong place.

- You probably need to delay disabling catching syscall-exits/looking
  for __dbx_link into the inferior_created observer, instead of disabling
  it at the end of procfs_create_inferior.

> I can send you the gdb.log file if you're interested. I suspect not ;-).

Not.  :-)

-- 
Pedro Alves