* [parisc-linux] We need our own libgcc-compat for a leaked __clz_tab
@ 2003-01-29 5:43 Carlos O'Donell
2003-01-29 16:50 ` John David Anglin
0 siblings, 1 reply; 2+ messages in thread
From: Carlos O'Donell @ 2003-01-29 5:43 UTC (permalink / raw)
To: parisc-linux
PA,
Problem:
- GCC used to export a symbol for __clz_tab (GLOBAL DEFAULT)
- Everything in debian is being built with newer tools (GCC 3.2).
- Symbol is no longer leaked (LOCAL HIDDEN)
- Libraries that had the leadked symbol are rebuilt (e.g. libcrypto)
- Binaries that had relocations against the symbol are failing (e.g.
wget)
Solution:
- Create a libgcc-compat in glibc for the symbol __clz_tab
= Various arches have them for certain symbols that were leaked
= from GCC when we the GNU tools didn't have ".hidden"
= So examples exist...
- Test the solution to see that atleast "wget" works.
- Put it into Debians glibc as a dpatch.
- Submit upstream for fame and glory.
I'm writing a paper and doing research until Saturday.
If someone feels gutsy enough to attempt a fix, please have at it...
If not, it's currently the highest priority item on my TODO.
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [parisc-linux] We need our own libgcc-compat for a leaked __clz_tab
2003-01-29 5:43 [parisc-linux] We need our own libgcc-compat for a leaked __clz_tab Carlos O'Donell
@ 2003-01-29 16:50 ` John David Anglin
0 siblings, 0 replies; 2+ messages in thread
From: John David Anglin @ 2003-01-29 16:50 UTC (permalink / raw)
To: Carlos O'Donell; +Cc: parisc-linux
> Problem:
>
> - GCC used to export a symbol for __clz_tab (GLOBAL DEFAULT)
> - Everything in debian is being built with newer tools (GCC 3.2).
> - Symbol is no longer leaked (LOCAL HIDDEN)
> - Libraries that had the leadked symbol are rebuilt (e.g. libcrypto)
> - Binaries that had relocations against the symbol are failing (e.g.
> wget)
>
> Solution:
>
> - Create a libgcc-compat in glibc for the symbol __clz_tab
> = Various arches have them for certain symbols that were leaked
> = from GCC when we the GNU tools didn't have ".hidden"
> = So examples exist...
> - Test the solution to see that atleast "wget" works.
> - Put it into Debians glibc as a dpatch.
> - Submit upstream for fame and glory.
As I said, this is a generic problem affecting all GCC ports. The
correct solution probably isn't adding the symbol to a PA specific
libgcc-compat in glibc. I think the matter needs discussion on
gcc@gcc.gnu.org. I'm not sure if there is a reason for hiding this
symbol. I would file a GCC PR.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-01-29 16:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-29 5:43 [parisc-linux] We need our own libgcc-compat for a leaked __clz_tab Carlos O'Donell
2003-01-29 16:50 ` John David Anglin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.