* Re: Moving Linux-specific stuff out of i386-tdep.c
[not found] ` <200003091349.IAA19958@indy.delorie.com>
@ 2000-04-01 0:00 ` Andrew Cagney
0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 22722 bytes --]
Eli Zaretskii wrote:
>
> > The 8.3 uniqueness rule definitly still applies.
>
> Should I post a list of files which violate that rule?
Sorry, applies when it matters - any files you need. :-)
Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000207093417.A10546@lucon.org>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00126.html
Content-length: 1540
On Mon, Feb 07, 2000 at 09:08:51AM -0800, Jim Kingdon wrote:
> > * Support for unloading of shared libraries. The current code-base
> > doesn't really support this. HJ Lu forwarded some patches that hack
> > around this, but I don't think they are acceptable. They introduce
> > two more (uneccessary) hooks. Personally I don't fixing this for
> > GDB 5.0 terribly important. There isn't that many code out there, that
> > explicitly unloads shared libs.
>
> As far as I know there is more out there than you might realize. A
> modern application like mozilla uses dlopen() a lot (feel free to
> flame about whether this tendency is a fad or really useful but that
> isn't the point). For example see
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130
>
>
> > I think having an "x86 linux native" port with working threads support
> > in GDB 5.0 is very important.
>
> Have you tried GDB from CVS in the last 6 months or so? I'm not aware
> of any known bugs and Red Hat Linux has been shipping with the code
> which is in CVS for a while (I can offer details if needed).
>
gdb 4.17.0.14 has one patch from Sam to deal with shared libraries.
People who want to debug shared libraries may not want to use gdb
in CVS. As you have mentioned above, it is not that unusual nowdays.
We have patches and they seem to work. We can make gdb 5.0 to work
with shared libraries. If we continue ignoring the working patches
without providing an alternative, we are sending the wrong signals
to those contributors.
H.J.
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Moving Linux-specific stuff out of i386-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C6D95A.FCEAE1C1@apple.com>
References: <200003082121.e28LLRu05681@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00623.html
Content-length: 2217
Mark Kettenis wrote:
>
> Hi,
>
> Over time quite a lot of Linux-dependent stuff has been added to
> i386-tdep.c, and I think it's time to move that into its own file.
Bear in mind that it should be possible to build a foo-x-linux
cross debugger, if for no other reason than to bootstrap new
systems. *-nat.c files are by definition native-only, and won't
get linked into a cross debugger.
I generally like to look at foo-tdep.c as a quasi-library of
knowledge about foo. It makes it easier to share code that
is the same or nearly the same for different OSes running on
the architecture.
> But before I do that I'd like to get some clarification on some
> issue's.
>
> 1. Do we still care about the filename limits of older System V
> systems? i386-linux-nat.c is longer than 14 characters which is a
> no-no according to the GNU conding standards.
Well, the systems in question are quite old, we've had long filenames
in GDB sources for quite a while, and only the DJGPP folks have
whined about it. :-) Personally, I think we should try to stay
within the 14-char limit, because a) everything gets unwieldy when
people start trying to put the documentation into the filenames
like i386-linux-nat-for-red-hat-6.1-beta2-except-in-nepal.c
and b) because doschk is a handy way to check on all the filename
issues at once.
If somebody has an actual System V machine that chokes when
handed a tar file with long filenames, now would be a good time
to speak up...
> 2. Should I postpone creating the new -tdep.c file until after the
> release or not. Andrew has been telling us to avoid gratuitous
> changes to make it easier to apply outstanding patches. But on the
> other hand, after 5.0 is released, I hope to see a lot new patches
> generated against 5.0. So creating the new file before 5.0 would
> make applying those new patches a lot easier.
If the Linux patch backlog were to be emptied out, you wouldn't have
this problem. :-) But seriously, if you change it now, before all
submitted patches have been dealt with, then it would only be fair
for you to adapt those patches yourself. So it seems more like a
question of whether you want to do more work now vs later.
Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: Stan Shebs <shebs@apple.com>, Mark Kettenis <kettenis@wins.uva.nl>, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E178BC.67987E6@cygnus.com>
References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00832.html
Content-length: 1723
"H . J . Lu" wrote:
>
> On Thu, Mar 09, 2000 at 04:53:39PM -0800, Stan Shebs wrote:
> > "H . J . Lu" wrote:
> >
> > > > A GNU/Linux distributor is free to build a GDB that regexp from an
> > > > installed glibc. Actually such a distributor is free to do what ever
> > > > they like :-)
> > >
> > > Are you saying as far as gdb is concerned, you have no interests
> > > whatsoever in glibc nor helping glibc developers and GNU/Linux
> > > distributors? If it is true, that is too bad.
> >
> > Let's not get all tense here! There's a balance to be struck between
> > being self-contained and depending on system stuff, and there's no
> > single rule that applies in all cases. For instance, GDB includes
> > libiberty, even though many of the functions are available on most
> > systems by default, including Linux, but I don't seem to hear anybody
> > complaining about that bit of redundancy. (Hmmm, why isn't regex
> > in libiberty anyway??)
> >
> > In the case of GDB on Linux, part of our problem is that we have
> > to support GDB on all versions of Linux, not just the latest
> > kernel and library. So if there is *any* version of glibc with
> > a problematic regex, say one from 4-5 years ago, we need to think
> > hard about whether we're going to hose people running a Linux that
>
> We can put some check to see if regex in glibc is in ok. From
> the glibc log in CVS, my simple check seems ok. I can even restrict
> it to glibc 2.1 and above. I don't think it should be any problem.
FYI,
I've put this all on hold until after 5.0.
Pokeing around glibc regex is ``on the move''. It continues to be
developed and fixed. One thing that has me wondering is i18n and what
effect that had on regex.
Andrew
From dj@delorie.com Sat Apr 01 00:00:00 2000
From: DJ Delorie <dj@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Moving Linux-specific stuff out of i386-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C6E28D.46F16538@delorie.com>
References: <200003082121.e28LLRu05681@delius.kettenis.local> <kettenis@wins.uva.nl> <1000308222742.ZM8876@ocotillo.lan> <20000308173031.A11900@cygnus.com> <1000308225132.ZM8953@ocotillo.lan>
X-SW-Source: 2000-q1/msg00629.html
Content-length: 930
Kevin Buettner wrote:
> Here's what Stan had to say about the matter:
>
> Names need to be 8.3 unique so djgpp works. The critical files...
> The 14-char thing is an old System V limitation, and is...
The key thing to note is that 8.3 filesystems truncate the *base*
name, not the whole file name. So, verylongfile.c becomes verylong.c
and the object file is verylong.o. With SYSV filesystems,
verylongfilename.c becomes verylongfilena and the object file
is *also* verylongfilena, and it overwrites the source.
So, "8.3" means 8.3 *unique*, but longer is OK (like the old FORTRAN
rules that variables could be long, but had to be unique in the
first six letters) as long as it gets safely truncated.
Also note that ftp.gnu.org has a package called "doschk" that
checks for 8.3-unique and sysv-14 problems. It's trivial
to build and use (ls -1R | doschk) and may prevent problems
down the road.
From phdm@macqel.be Sat Apr 01 00:00:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb@sourceware.cygnus.com
Subject: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003241301.OAA04488@mail.macqel.be>
X-SW-Source: 2000-q1/msg00794.html
Content-length: 904
Up to some years ago, gdb could be compiled by a K&R C compiler.
Now, it can not anymore, and the change seems to be deliberate.
It seems to me that the freedom of the gdb users is now restricted compared
to the previous versions because of the need of an ISO-C compiler instead
of any C compiler to compile it.
And I do not understand why the same reasons that apply to binutils and gcc
do not hold for gdb. gdb, because it is better than the debugger you get
with your operating system, is needed to bootstrap the installation of
gas, gld, or gcc in the likely case that not everything works well
the first time.
Just my opinion
Philippe
P.S. : I am willing to check that gdb can be compiled by a K&R compiler
and submit the needed patches, if that can help.
Philippe De Muyter phdm@macqel.be Tel +32 2 702 90 44
Macq Electronique SA rue de l'Aeronef 2 B-1140 Bruxelles Fax +32 2 702 90 77
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Frank Ch. Eigler" <fche@cygnus.com>
Cc: gdb@sourceware.cygnus.com, johan.rydberg@netinsight.se
Subject: Re: problem with register display
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C7A12A.707179E3@cygnus.com>
References: <38C6691D.C3F05223@netinsight.se> <o566uxjty7.fsf@toenail.to.cygnus.com>
X-SW-Source: 2000-q1/msg00641.html
Content-length: 524
"Frank Ch. Eigler" wrote:
> > And, how do I from gdb call the `sim_info´ function? [...]
>
> I see no gdb command that hooks to this function. But, one is not
> hard to add. Look up the sim option processing functions. They work
> from both within gdb (using the "sim" command prefix) and the sim
> command line (as long --options).
Try ``info target'' (or ``info files'').
Looking in gdb/remote-sim.c it would appear that sim_info() is called
conditional on there being an executable. I can't think why.
Andrew
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Jim Kingdon <kingdon@redhat.com>, Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A464AF.535C7505@apple.com>
References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> <bg0v08f69.fsf@rtl.cygnus.com> <200002111929.OAA13997@mescaline.gnu.org>
X-SW-Source: 2000-q1/msg00226.html
Content-length: 886
Eli Zaretskii wrote:
>
> Andrew Cagney writes:
>
> > > So having said all that, do you still want submit.html or equivalent
> > > in the distribution? Having it both places seems like kind of a
> > > maintenance pain and seems to me that having the distribution point
> > > to the web site probably works.
> >
> > Yes, I think the GDB distribution should contain the document.
>
> Perhaps it is better to make this document part of the GDB manual.
> Then we could be sure it won't be forgotten due to changing fortunes
> of time...
The GDB manual is for users only, so not really appropriate there. The
internals manual does have a section on contributing, but it could use
some tinkering.
We should consider installing more links from the web pages to htmlized
copies of manuals - that should help improve awareness that the manuals
already contain a lot of useful info.
Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: 5.0 known issues 2000-02-16
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BF7E1D.4E0A904D@cygnus.com>
References: <38AA42EA.5106E153@cygnus.com> <87ael1ynl8.fsf@cygnus.com>
X-SW-Source: 2000-q1/msg00516.html
Content-length: 354
Tom Tromey wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>
> Andrew> GNU/Linux/i386:
>
> Without my patch, gdb doesn't work at all when run on x86 Linux boxes
> with older kernels (I still run 2.0.34).
Tom,
I belive JimB's bubbled this up to the top of his queue and made it one
of the things try to get into 5.0
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Gabor Z. Papp" <gzp@gzp.org.hu>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb cvs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BF0551.9B4FE1E@cygnus.com>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu> <20000302204824.B18856@gzp.org.hu>
X-SW-Source: 2000-q1/msg00514.html
Content-length: 299
"Gabor Z. Papp" wrote:
>
> | cvs server: Updating gdb
> | U gdb/CONTRIBUTE
>
> [...]
>
>
> Is this correct?
Were you doing a: ``co gdb'' over the top of an existing tree? I've
encountered that message then.
I suspect it isn't correct but, from what I saw it still did what I
wanted.
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: --target=powerpc-elf broken in current sources?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A8ACD1.E343CD0C@cygnus.com>
References: <200002150108.RAA03716@haight.constant.com>
X-SW-Source: 2000-q1/msg00280.html
Content-length: 406
Benjamin Kosnik wrote:
>
> > try on older linux release yadda yadda yadda
>
> No. I haven't. Is gdb only working on older linux releases?
To put it another way, is there any thing to suggest that this is a
generic build problem or something specific to your Linux host?
The powerpc simulator contains some pretty scary linux emulation code.
I can imagine that suffering from decay over time.
Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: blizzard@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002181853.e1IIr1t02301@delius.kettenis.local>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com> <20000218101700.A19913@lucon.org>
X-SW-Source: 2000-q1/msg00340.html
Content-length: 1098
Date: Fri, 18 Feb 2000 10:17:00 -0800
From: "H . J . Lu" <hjl@lucon.org>
On Fri, Feb 18, 2000 at 12:42:01PM -0500, Chris Blizzard wrote:
> Christopher Blizzard wrote:
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > 0x404cbd41 in ?? () from /lib/libc.so.6
> > (gdb) shar libc.so.6
> > Reading symbols from /lib/libc.so.6...done.
> >
There are many linuxthreads problems since lin-thread.c was
introduced. Unfortunately, I don't have the time to track it
down.
This isn't one of them (at least the problem that was origionally
reported by Jim Kingdon). The bug report is from before lin-thread.c
was introduced. As a matter of fact, I have seen a spurious SIGTRAP
on Solaris 2.6 too in the gdb.threads/pthreads test. And I also see
them quite frequently on the Hurd too (where every program is
multithreaded). Looks like there is something wrong in the platform
independent threads code.
As for the "many linuxthreads problems": would you please tell us what
they are. Apart from the spurious SIGTRAPs I'm not aware of any.
Mark
From jsm@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jsm@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: GDB Developers <gdb@sourceware.cygnus.com>
Subject: Re: GDB ftp site in hyperspace ...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000131225201.A11482@cygnus.com>
References: <200002010648.WAA28893@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00082.html
Content-length: 707
On Mon, Jan 31, 2000 at 10:48:42PM -0800, Todd Whitesel wrote:
> I just tried to ftp a fresh tarball of 4.18, but the ftp.cygnus.com site
> claims the directory has moved to sourceware, yet the /pub/gdb directory
> on sourceware appeared empty...
>
> I used the shell ftp client on solaris... What gives?
The shell ftp client on Solaris is broken. Use another client, such as
ncftp or netscape, to browse the ftp site. Or use another OS, say... oh
I don't know... maybe Linux? :-)
(I'm not joking about the Solaris ftp client being broken; I think it
will still work if there is at least one file in a given directory. The
directory you're looking at has no files in it, only subdirectories)
Jason
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gatliff@haulpak.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdbstubs library posted at sourceforge
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200001271910.OAA04242@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00062.html
Content-length: 849
> I just moved my gdbstubs library to sourceforge.net.
Cool! I've added a link from http://sourceware.cygnus.com/gdb/ - at
the bottom of the page with the other links.
> The release license is LGPL.
Are you sure you want this rather than public domain (as the stubs in
the GDB distribution) or XFree86-style? I suppose maybe it is a moot
point if people leave out the stubs when they actually ship code, but
in general, the LGPL's requirement that people make available .o's
makes it somewhat impractical for many embedded applications.
> I'll also take any suggestions on how to manage the project--- I'm not
> exactly skilled in the art of extreme multitarget development, at
> least not yet. :^)
You've already done the hard part by being dumb ^H^H^H^H brave enough
to start the project! Feel free to ask if you have specific
questions.
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003040704.CAA08168@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <200003031240.e23CeRn00162@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00536.html
Content-length: 170
> The suggested syntax could probably be
> improved, since "xx" isn't very descriptive. People with bright ideas?
How about "x/seg=SEG OFFSET"? Or simply "x SEG:OFF"?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Anthony Green - Java Maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C71B06.94E21103@cygnus.com>
X-SW-Source: 2000-q1/msg00631.html
Content-length: 2168
Hello,
I've made Anthony Green the Java maintainer.
enjoy,
Andrew
Thu Mar 9 14:21:07 2000 Andrew Cagney <cagney@b1.cygnus.com>
* MAINTAINERS (Core): Anthony Green is the Java - including
testsuite - maintainer. Reformat testsuite and language support
sections
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.21
diff -p -r1.21 MAINTAINERS
*** MAINTAINERS 2000/03/05 08:46:56 1.21
--- MAINTAINERS 2000/03/09 03:26:56
*************** maintainers when resolving more generic
*** 56,62 ****
The host maintainer ensures that gdb (including mmalloc) can be built
as a cross debugger on their platform.
- hp testsuite (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com
djgpp native *Eli Zaretskii eliz@gnu.org
DJ Delorie dj@cygnus.com
MS Windows (N.T., CE, '00) host & native
--- 56,61 ----
*************** tracing Michael Snyder msnyder@cygnus
*** 90,96 ****
threads Michael Snyder msnyder@cygnus.com
breakpoint.c Michael Snyder msnyder@cygnus.com
language support David Taylor taylor@cygnus.com
! C++ language support Daniel Berlin dan@cgsoftware.com
expression eval David Taylor taylor@cygnus.com
defs.h David Taylor taylor@cygnus.com
utils.c David Taylor taylor@cygnus.com
--- 89,96 ----
threads Michael Snyder msnyder@cygnus.com
breakpoint.c Michael Snyder msnyder@cygnus.com
language support David Taylor taylor@cygnus.com
! C++ support Daniel Berlin dan@cgsoftware.com
! Java support Anthony Green green@cygnus.com
expression eval David Taylor taylor@cygnus.com
defs.h David Taylor taylor@cygnus.com
utils.c David Taylor taylor@cygnus.com
*************** rdi/adp protocol Fernando Nasser fnasse
*** 108,113 ****
--- 108,115 ----
gdbserver Stan Shebs shebs@apple.com
documentation Stan Shebs shebs@apple.com
testsuite Stan Shebs shebs@apple.com
+ hp tests (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com
+ Java tests (gdb.java) Anthony Green green@cygnus.com
Kernel Object Display Fernando Nasser fnasser@cygnus.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: muller@cerbere.u-strasbg.fr, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: RFD: New command to inspect other selectors memory.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003040706.CAA08171@indy.delorie.com>
References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> <200003030843.JAA12246@cerbere.u-strasbg.fr> <38BFB50A.606036CF@cygnus.com>
X-SW-Source: 2000-q1/msg00537.html
Content-length: 232
> The theory is that if ``CORE_ADDR'' is made in to a pretend object
> (ISO-C remember :-) and then the rest falls out.... As they say, the
> proof is left as an exercise to the reader.
Sorry, I don't follow. Can you elaborate?
^ permalink raw reply [flat|nested] 4+ messages in thread