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]

Re: [PATCH] move __gmon_start__ call out of .init section


> 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]