Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz
2006-02-05T20:20:47Z

On Sun, Feb 05, 2006 at 10:00:24PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 4 Feb 2006 23:39:17 -0800
> > From: Jim Blandy <jimb@red-bean.com>
> > Cc: gdb-patches@sourceware.org
> >
> > On 2/4/06, Eli Zaretskii <eliz@gnu.org> wrote:
> > > > Date: Sat, 4 Feb 2006 21:01:14 -0500
> > > > From: Daniel Jacobowitz <drow@false.org>
> > > >
> > > > I think that mingw32 hosting support and mingw32 native support can be
> > > > treated separately; do you disagree?
> > >
> > > I do. I think they should be treated together, as having a cross
> > > debugger that cannot debug natively is kinda silly.
> >
> > I don't think it's silly. If you are using Windows as a platform for
> > cross-development, you may not even have shelled out the bucks for a
> > native compiler. In that situation, why would it be ridiculous to
> > have a debugger that, like your compiler, is only useful debugging
> > programs on your cross target?
>
> Reality check: how many other non-embedded platforms have their cross-
> and native targets separated?

Could you clarify what you mean by this? As far as I can interpret it,
the answer is "every".

We have three kinds of support. Cross target, native target, and
general host. We've labored for years to keep cross target and native
target completely separate. General host is normally distributed
through all of GDB - except for e.g. the serial files.

You never build a debugger with just one; normally you want one from
column A, zero or one from column B, and one from column C. In a
pure multi-arch world you want one or more from column A, but the other
columns are unchanged.

> > Also, the kinds of things needed to host GDB on a platform are best
> > kept partitioned away from the stuff needed for doing native target
> > debugging, simply as a matter of design. It's a simple matter of
> > separation of concerns.
>
> Then please explain why do we compile ser-unix.c with native Unix
> targets, and ser-go32.c with the DJGPP native target.

I'd call that a perfect example of Jim's point. You don't _need_
ser-unix.c to do native debugging; that's the partitioning at work.
It's included as a side effect of the fact that a native target depends
on also having a cross target. Thus a native Unix GDB can debug a
remote Unix program (and I do this every week). A native DJGPP GDB
could also debug a remote DJGPP program (if there were an appropriate
remote stub, I don't know).

--
Daniel Jacobowitz
CodeSourcery