This is the mail archive of the mailing list for the GCC project.

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

Re: PATCH: Share the dwarf2 unwind code between glibc and gcc 3.0

> Date: Mon, 9 Jul 2001 00:30:20 -0700
> From: "H . J . Lu" <>

> On Sun, Jul 08, 2001 at 08:42:46PM -0700, Geoff Keating wrote:
> > "H . J . Lu" <> writes:
> > 
> > > Here is my gcc patch to share the dwarf2 unwind code between glibc and
> > > gcc. I will send patches for gcc 2.95/2.96 to do the same. Combine them
> > > together in glibc, glibc can support mixed v2 and v3 unwind frames,
> > > independent of the gcc version used to compile glibc.
> > 
> > Before this patch is approved, I want to see an English explanation of
> > the resulting design, not just uncommented code spread across two
> > projects.  I recommend documenting this in the GCC and glibc manuals.
> > I am willing to help write the documentation if you can explain the
> > new design to me.  I will VIOLENTLY OBJECT to this patch being
> > committed without proper documentation!!!!
> There have been some lengthy discussions on it. I posted a few patches
> based on them, including the latest one.

I have seen no documentation patches from you.  I have seen
code, and some e-mail discussion, which is good, but no documentation;
nothing that someone can look at in a year's time to try to understand
the implementation.  Can you point me at documentation patches?

> > 
> > Why does GCC need this patch?  Shouldn't the patch be against glibc?
> > 
> > I don't understand what you mean by "share the dwarf2 unwind code".
> > There should be only one copy on a system at a time.  Either that copy
> > is from GCC or from glibc, but if there is only one of it, the copy
> > cannot come from two places.  
> Exactly. They have to be the same in functionality. By `shaere', I
> meant the same code can be used in both gcc and glibc so that we are
> sure either copy will do the job right.

Only one copy can be used.  Which copy should it be?  Or do you intend
that the last one installed wins?  Have you tested this?

> > >From a user's point of view, if this code is updated, it should not be
> > necessary to rebuild both GCC and glibc.  One or the other, but not
> > both.
> > 
> What do you mean by that? My patch shouldn't change anything in gcc.
> It just makes it possible to compile the same gcc code in glibc.

I mean, I don't understand how you think this should work, and I want
to see documentation.

> > I would also suggest having the documentation written and approved
> > first, before the patch goes in.  This will save the trouble of
> > backing the patch out later if it turns out the design could be
> > improved.
> I am all for documentation. I also requested for a libgcc ABI
> documentation. We shouldn't make any ABI changes in libgcc anymore.

Not just the ABI, although that is certainly necessary, but an
interface document that says which parts glibc is responsible for, and
which parts are from GCC, and how the parts interact, and which parts
change, and which parts don't change, and which parts get tested, and
what does the testing, and how the parts get updated, and how system
integrators package them, and so on.

> Can we have it now since we are on it?

Yes.  If you write some documentation, I will review it.

- Geoffrey Keating <>

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