Re: RFC on how to implement something between solib-irix and procfs

Joel Brobecker
2004-07-05T02:11:22Z

> My question is: Where should I put the code: I need to do some procfs
> operations from solib-irix. I was thinking of having all the code doing
> the procfs stuff inside procfs.c, and call that code from solib-irix.c
> until I get the __dbx_lin() address. But at the same, it seems to me
> that solib-irix.c is a target-dependent file, while procfs.c is
> host-dependent. So it is not impossible that a cross-debugger be built,
> making my procfs operations unavailable (assuming I can link, which is
> not guarantied either).

I think I found an approach that should work (untested):

1. Add some code in procfs_init_inferior some code that will add
syssgi() syscall exit notification (#ifdef SYS_syssgi).

The idea is that, when irix_solib_create_inferior_hook() does the
target_resume(), the SYS_syssgi exit notification have already been
setup automatically iff appropriate (ie iff procfs is the target).
So when this routines does the target_resume, either:

+ We don't use procfs, and we'll just hit our entry point breakpoint.
Oh well, we're just in the same situation as we have always been.
Nothing's changed, so we do as we have done in the past.

+ Or, we use procfs, in which case the inferior will stop on
the first syssgi() call exit event before our entry point.

We will now suppose that we use procfs. So after we have resumed
the inferior, it stopped on the first SYS_syssgi exit event.

2. I will add some code in procfs_wait() to detect such events, and
do the following:

+ Search the text regions for __dbx_link.
+ If found, then: - Insert a breakpoint there
- Remove SYS_syssgi() exit notifications.
+ resume the target and start over (goto wait_again).

The intent is to put the procfs_wait() routine into a wait until
we can find the routine we're looking for. As soon as this is done,
then insert the breakpoint, and continue. This is all transparent
to solib-irix.c.

3. Add some code again in procfs_wait() to detect when we reach
the breakpoint that we just inserted (by detecting breakpoint
events occurring at the address where the brekapoint was inserted).
Remove the breakpoint before returning from the function.

At this point, the control eventually returns to
irix_solib_create_inferior_hook(), which knows we just stopped on a
breakpoint. Up to now, it checks that we landed where it inserted
its own breakpoint (at the entry point), but this is no longer a
valid assertion, as we may have landed in __dbx_link() instead.

4. So I'll remove the check in solib-irix.c:disable_break().

After that, irix_solib_create_inferior_hook() is just free to load
the symbols of all shared libraries as usual, and continue as before.

The last bit that's left to do is to answer the following question:
What if the inferior does *not* use shared libraries. If you follow
the algorithm above, you'll find that GDB will never detect __dbx_link
and therefore will never remove the SYS_syssgi exit notification. Each
time the inferior makes a call to syssgi(), we'll end up stopping the
inferior, checking all the text memory regions, and then restarting the
inferior.

To avoid this, I will modify procfs_create_inferior() to remove
the SYS_syssgi exit notification after the call to fork_inferior.

Sounds OK?
--
Joel