Bug 4457 - Allow ports a simple override of "libgcc_s.so.1" in sysdeps/generic/framestate.c
Summary: Allow ports a simple override of "libgcc_s.so.1" in sysdeps/generic/framestate.c
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.6
: P3 enhancement
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-03 06:31 UTC by Carlos O'Donell
Modified: 2014-07-04 16:36 UTC (History)
1 user (show)

See Also:
Host: hppa-linux-gnu
Target: hppa-linux-gnu
Build: hppa-linux-gnu
Last reconfirmed:
fweimer: security-


Attachments
[PATCH] Allow override of "libgcc_s.so.1" in framestate.c (621 bytes, patch)
2007-05-03 06:32 UTC, Carlos O'Donell
Details | Diff
Another attempt (1.43 KB, patch)
2009-08-23 18:53 UTC, mkuvyrkov
Details | Diff
Set libgcc_s' version for m68k and hppa (733 bytes, patch)
2009-08-23 18:55 UTC, mkuvyrkov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos O'Donell 2007-05-03 06:31:09 UTC
The file sysdeps/generic/framestate.c has a hardcoded value of "libgcc.so.1".
Some architectures have bumped the so version on libgcc_s and therefore the
hardcoded value is wrong.

It would be nice if ports could write:
ports/sysdeps/$target/framestate.c:
#define LIBGCC_S_SO "libgcc_so.so.2"
#include-next <framestate.c>

There are other alternatives but this one seemed the simplest and easiest to
maintain.

Patch attached.
Comment 1 Carlos O'Donell 2007-05-03 06:32:48 UTC
Created attachment 1746 [details]
[PATCH] Allow override of "libgcc_s.so.1" in framestate.c

This patch allows the override of "libgcc_s.so.1" in
sysdeps/generic/framestate.c.

Tested without regressions on hppa-linux-gnu.
Comment 2 Jakub Jelinek 2007-05-07 15:40:07 UTC
framestate.c is so short that I wonder if it isn't better just to duplicate
the file in ports.
Comment 3 Ulrich Drepper 2007-05-07 22:12:36 UTC
Not like this.  Provide a patch which determines the correct name, adds it to
the names in the generated gnu/lib-names.h, and then use that name in framestate.c.
Comment 4 Ulrich Drepper 2007-08-22 07:15:23 UTC
No reply in 3+ months.  Closing.
Comment 5 mkuvyrkov 2009-08-23 18:53:34 UTC
Created attachment 4144 [details]
Another attempt

Hello,

The attached patch makes another attempt to fix this issue.

It doesn't implement exactly the solution Ulrich proposed above in that it
doesn't detects the version of libgcc_s.so installed.  Instead, the patch make
GLIBC to rely on shlib-versions files to specify it.

The entry in top-level shlib-versions file specifies the version of libgcc_s to
be '1' (what most architectures have) and shlib-versions in sysdeps directories
can override that.

FWIW, making GLIBC to autodetect the version of libgcc_s installed does not
seem trivial to me.
Comment 6 mkuvyrkov 2009-08-23 18:55:27 UTC
Created attachment 4145 [details]
Set libgcc_s' version for m68k and hppa

This patch sets libgcc_s' version to 2 for m68k and to 4 for hppa.

The combined patch was tested on m68k and powerpc.
Comment 7 mkuvyrkov 2009-08-23 18:56:41 UTC
Would please maintainers kindly consider the patches attached above?
Comment 8 mkuvyrkov 2009-10-26 20:09:57 UTC
Ping.

Would maintainers please kindly consider the patches in the attachment.
Comment 9 Carlos O'Donell 2009-11-08 18:46:19 UTC
This is now fixed on trunk by these patches. 

This fix will be part of 2.11 given that the 2.11 branch happens from trunk.

/

2009-11-03  Andreas Schwab  <schwab@linux-m68k.org>

[BZ #4457]
* sysdeps/generic/libgcc_s.h: New file.
* sysdeps/generic/framestate.c: Include it and use LIBGCC_S_SO.

nptl/

2009-11-03  Andreas Schwab  <schwab@linux-m68k.org>

[BZ #4457]
* sysdeps/pthread/unwind-resume.c: Include <libgcc_s.h> and use
LIBGCC_S_SO.
* sysdeps/pthread/unwind-forcedunwind.c: Likewise.

Comment 10 Carlos O'Donell 2009-11-08 18:55:23 UTC
Per the new bugzilla procedure I've opened new issues for m68k and hppa to
provide libgcc_s.h.