This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC/RFA] Target vectors for native Linux targets
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: uweigand at de dot ibm dot com
- Cc: manjo at austin dot ibm dot com, gdb-patches at sources dot redhat dot com
- Date: Sun, 21 Aug 2005 17:20:59 +0200 (CEST)
- Subject: Re: [RFC/RFA] Target vectors for native Linux targets
- References: <200508211328.j7LDSVhH003835@53v30g15.boeblingen.de.ibm.com>
> From: Ulrich Weigand <uweigand@de.ibm.com>
> Date: Sun, 21 Aug 2005 15:28:31 +0200 (CEST)
>
> Mark Kettenis wrote:
>
> > Hmm, it would be preferable to have it the other way around, since
> > that would make eliminating the nm-linux.h files, but I can see why
> > you did it this way. In the end we might just define USE_LINUX_TARGET
> > if GDB_NM_FILE isn't defined. So it's not really important. I've
> > added some more comments on the patch inline.
>
> I guess we could make a config/nm-new-linux.h or something -- that
> would be a (temporary) new nm file, but would allow to remove the
> per-platform Linux nm files as platforms are converted over ...
Don't bother. All the cruft in there has to go away eventually.
Making it more cruftier in the meantime isn't a problem.
> > Indeed. When I did conversions in the past the
> > depreceated_xfer_memory always came back to haunt me, so we have to be
> > a bit careful. Did you test your patch on another Linux target that
> > wasn't converted yet?
>
> I tested it on s390 *without* the follow-up patch, and that went
> fine as well ...
Should be. Although it wouldn't hurt if people tested this patch on
their favourite Linux system.
> > Daniels earlier attempt had linux_target accept a `struct target_ops
> > *' as an argument to serve as an alternative for a plain
> > inf_ptrace_target(). I thought that was necessary for i386 and sparc
> > Linux targets, but I think I've convinced myself that it isn't.
>
> Since you can always override the target functions afterwards,
> I'm not sure why this would be necessary ...
I think Daniels earlier patch did things a little bit differently,
eliminating the Linux pseudo-LWP layer. That made overriding things
afterwards more difficult. All the more reason to go with your patch
instead of reviving Daniels old one.
Mark