This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: BP status?


Andreas Jaeger <aj@suse.de> writes:

> Could you give some details about the current status?

I'm mostly working on getting glibc changes checked in, which will
probably take another week or so.  I'll announce when it's ready for
testing.

After glibc, I have a big pile of gcc changes to commit.  That might
take many weeks, since patch approval latency is much longer.
However, BP gcc is available right away since I have all my changes on
a branch.

> Does it make sense to test builds with bounded pointers?

Not yet.  Testing BP builds will be a good idea as soon as I have all
glibc changes checked in.

> On which architectures does it work?

It mostly works on ix86: gcc bootstraps with BP glibc.  It almost
works on PowerPC: there are still a few gcc bootstrap problems.
Targets I will work on next are MIPS and i960.  After that, if I have
time, and no one else has done them yet, I'll do on IA-64, SPARC and
Alpha.

> I guess I need the current gcc from CVS for this - or
> do I need extra patches for GCC?

My compiler changes are on a CVS branch: bounded-pointers-branch.

> I'd appreciate if you could write some documentation about the bounded
> pointer support when you're finished.  This should be added to the
> manual and perhaps also to the FAQ.

I don't see that there's much to write about BPs in the glibc manual,
just as there's very little to write about the static debug or
profiling versions of glibc: they implement API-compatible drop-in
replacements and are thus transparent to the user.  By contrast, the
debug and profiling versions are also ABI-compatible whereas the BP
version is not.  IMO, BPs are more properly documented in the gcc
manual and the glibc manual need only refer the reader to the gcc
manual.  What do you think?

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]