| Summary: | arm-none-eabi-linux-gnueabi doesn't build | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Kazu Hirata <kazu> |
| Component: | ports | Assignee: | drow <drow> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | glibc-bugs |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | arm-none-eabi-linux-gnueabi | |
| Build: | Last reconfirmed: | ||
|
Description
Kazu Hirata
2006-05-19 18:38:43 UTC
The patch is to sysdeps/generic/initfini.c, and seems obvious. I could create an ARM-specific initfini.c to work around this, but is that really necessary? There is no reason in general that function should not be inlined. It really should be inlined. Perhaps you can find a fix for the arm build that does not deoptimize the code. Subject: Re: arm-none-eabi-linux-gnueabi doesn't build
On Fri, May 19, 2006 at 07:22:53PM -0000, roland at gnu dot org wrote:
> There is no reason in general that function should not be inlined.
> It really should be inlined. Perhaps you can find a fix for the arm build that
> does not deoptimize the code.
Then I'll mark it non-inlined in an ARM copy; but I expect this to
cause problems on many other targets. It only materializes on very
recent versions of GCC, because previously we used -fno-unit-at-a-time
which suppressed the "inline static functions called once"
optimization; if GCC is new enough we use -fno-toplevel-reorder
instead.
Sedding GCC's assembly output has historically worked "well enough" for
simple calls to known static functions, but it's not surprising that
call_gmon_start requires a constant pool. I expect to see similar
problems at least for SH.
Anyway, you want an ARM-only fix, you'll get one :-) I'll take care of
it.
Change was checked in earlier in the year: 2006-05-30 Daniel Jacobowitz <dan@codesourcery.com> * sysdeps/arm/initfini.c: New file. |