This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> The problem is that the unwind info for the .init/.fini section will > be incorrect if it contains any function call. I don't really see why it should matter for these functions (when do you unwind through them?), but I can take your word for it that it does. > That's true, but .init is deprecated on ia64 anyhow. If legacy code > doesn't get profiled because it was using .init, I doubt that's a big > loss. Ok. > Perhaps the call could be moved into .preinit_array? I'm not entirely > sure whether that would be safe though. It's a weak reference and so might be zero. There is no provision in the spec for preinit_array elements being zero, so it would be questionable to have it skip them (rather than a user putting a random zero into the array getting the crash he deserves). It sounds like this is really an ia64-specific issue and so there isn't any question of wanting to do this for the other platforms. So I will put your change in. Please fix whatever you are using to munge your diffs so that it produces correct file names instead of the garbage all your recent patches have contained. After today I won't be in the mood to manually unmunge patches that can't be applied by any single -pN setting. Thanks, Roland
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |