Greetings, and thank you so much for your reply on this issue! Please let me preface the below with the statement that these are, of course, my opinions only, and that there may well be issues of which I'm unaware which may contraindicate my conclusions.
Briefly, I think this is a bug in libc6 because: 1) It makes stable unexeced binary images, to my understanding, impossible. Unexecing, while by no means the dominant method for making binaries, has a long history in unix, most notably serving at the base of emacs compilation, but also in like manner gcl and the (growing number of) images build atop gcl, currently maxima, acl2, and axiom. I believe that for some time this issue stood in the way of an emacs on ia64 linux. Apparently there has been some workaround put in place, but on searching the archives and the code base, I cannot find it. I've had a helpful suggestion from a reader of debian-ia64 that I should modify the gcl's unexec to dump the portion of the descriptor table containing internal function addresses into the image itself as a runtime override of ld.so's work, but this appears both desperate and fragile. 2) ld.so's changing of the function descriptor table is (apparently) unnecessary, albeit possibly permitted by the ABI. To my knowledge, the Debian port to hppa faced similar issues, yet the implementation arrived at is free of this problem. In addition, the same helpful respondent referred to above suggested three ways in which this problem could be addressed at the ld.so level: ============================================================================= If this analysis is correct, I suspect there are multiple ways to fix the problem: - One possibility might be to have the link editor reserve the necessary space so that make_fptr_table() can map this reserved space, rather than allocating anonymous memory via mmap(). Downside: requires changed to both the link-editor and the runtime loader and I'm not sure how the runtime loader would locate the reserved-space section. - Another possibility might be to change make_fptr_table() to use sbrk() instead of mmap() when it allocates the descriptor table for the main program. Downside: I'm not sure it's safe for the runtime loader to change the process' break-value. - A third possibility might be to materialize function pointers for the executable program at link time (rather than at load time). I think the ELF symbol resolution rules would allow that, but I'm not sure whether it would be easy to make these descriptors visible to shared objects. Hmmh, none of these look terribly attractive to me. Richard, what do you think? ============================================================================= 3) The ld.so ia64-specific behavior is clearly the root of the tree of these problems, and is the logical place to address them all once and for all. And, unless the ABI mandates that the descriptors *must* change across runs, implementing the descriptor table creation in a manner consistent with function addressing use on all the other Debian platforms is bound to improve the consistency, continuity, and robustness of the distro as a whole. To be more precise, the alternative to an ld.so fix is for every program from now on which ever uses unexec to put in and maintain lengthy ia64 specific #ifdef'ed modifications. Anyway, these are just my thoughts. Take care, Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Sat, Oct 25, 2003 at 02:04:47PM -0400, Camm Maguire wrote: > > reaassign 217484 libc6 > > severity 217484 important > > merge 217484 204789 > > thanks > > > > Greetings! This is due to the way libc6 on ia64 Debian linux (only) > > recalculates function descriptors at runtime depending on the exact > > version of the shared libs present, ostensible soname compatibility > > notwithstanding. A simple recompile on the box on which gcl will run > > is a workaround. If this cannot be fixed, we will have to ensure gcl > > is synchronized with its shared lib dependency packages when > > finalizing sarge. > > I still don't understand why you consider this behavior to be a bug in > libc6. The ia64 ABI does not promise that function descriptors will > remain constant even across runs, as far as I know. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
