This is the mail archive of the gcc-patches@gcc.gnu.org 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]
Other format: [Raw text]

Re: PATCH: PR ia64/14925: libunwind enabled gcc generates incompatible libgcc_s.so.1


Thanks, Jim. This is the updated mainline patch I am going to check
in. I will check into 3.4 after it is opened.

On Fri, Sep 03, 2004 at 04:24:55PM -0700, James E Wilson wrote:
> On Thu, 2004-08-26 at 08:03, H. J. Lu wrote:
> > They have been tested on ia64, ia32 and x86_64. Are they OK for
> > mainline and 3.4?
> 
> Sorry about the delays, the MIPS vector work has been keeping me very
> busy, and I had to put this off for a while.
> 
> Since I looked at an earlier version of the patch, and it seemed
> reasonable then, I don't have any serious issues with this, just a
> number of minor issues.
> 
> I noticed that SHLIBUNWIND_LINK and SHLIBUNWIND_INSTALL are passed to
> recursive makes, but there is no default definition for them, which
> looks a little strange.  They are only used in LIBUNWIND is defined, so
> this seems harmless, but still I think it looks a little better if you
> add empty definitions for them next to LIBUNWIND.

Done.

> 
> Since we have multiple t-*libunwind* files, it would be nice if each had
> a comment explaning what it is for.  I think the config/t-libunwind file
> should have a comment at the top that says something like "Use the
> system libunwind library."  The t-libunwind-elf file looks OK.  The
> ia64/t-glibc-libunwind file could use a comment, e.g. "Build libunwind
> for IA-64 GLIBC based system."  The ia64/t-glibc needs a comment like
> "Use system libunwind library on an IA-64 GLIBC based system."

Done.

> You have a comment in install.texi that refers to gcc-3.4.2.  This
> unfortunately has to be gcc-3.4.3 now.

Done.

> 
> In gcc.c, you are adding -lunwind before -lgcc, but there is already a
> -lunwind after -lgcc.  Why?  Do we really need two of them?  There is
> also the question that if the library order has to change for the static
> case, then does it also change for the shared case right below?
> 

We have

static void
init_gcc_specs (struct obstack *obstack, const char *shared_name,
                const char *static_name, const char *eh_name)

EH routines are moved from libgcc_s.so to libunwind. It will be clearer
to add -lunwind to SHARED_NAME. libunwind doesn't require libgcc_eh.a.
It should be OK to place it after -lgcc_eh. 

> Otherwise this all looks OK to me, for both mainline and the gcc-3.4.x
> branch.


H.J.

Attachment: gcc-3.5-libunwind-4.patch
Description: Text document


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