This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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] |
Craig Howland <howland@LGSInnovations.com> writes: > It's no difference than a weak alias--it requires object file support. To quote > from the GCC manual about a function alias attribute (which is what the macro > ends up using), "This attribute requires assembler and object file support, and > may not be available on all targets." It is different from weak in that it doesn't require any object file or linker support. For instance, here's what the __strong_reference does in e_acos.c: .globl acos .set acos,__ieee754_acos Using __weak_reference does this instead: .weak acos .equ acos, __ieee754_acos The GCC docs don't really talk about non-weak aliases at all which makes me unhappy as it would be useful to know if the statement you quoted refers to *all* aliases, or only weak aliases. However, given the current GCC docs, we'll certainly want to use a separate conditional instead of attempting to auto-detect this mode. I'll add that, but I won't add any autotools mechanism to define it as I cannot rebuild the configure scripts on Debian any longer. I'm not getting a sense of whether you think this is a useful change though; it seems like a fairly obvious optimization of the existing feature to me, but perhaps you're finding it too complicated to be useful upstream? -- -keith
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |