Re: rtld messing up?
Last month, Mark Murray [EMAIL PROTECTED] wrote: In ports/lang/gcl, a program is undumped, and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. I've also have had that same problem when I tried to build the port, but was never able to find the reason for the program to segfault, I even opened a PR on that. The program seems to work on NetBSD btw.=20 PR ports/34661 :-) Has anyone gotten any further on this? I took a look at ports/34661, but nothing new has been added to it. Using 4-STABLE (sorry, I'm not using -current), I took a quick stab at the problem (having dealt with XEmacs undump issues in a past life), but I haven't gotten anywhere, yet: XEmacs uses unexelf.c, whereas gcl uses unexec.c. Changing gcl to use unexelf.c didn't change anything, but the next step is to compare the two unexelf.c's (they are different). The core stack trace seems to imply that there's some constructor initialization issue that undump isn't handling properly. -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rtld messing up?
[ cc'd to ports (re: ports/34661). The problem here is that gcl, in
ports/lang, is not building due to a core dump. This patch might
fix it. ]
I wrote:
PR ports/34661 :-)
Using 4-STABLE (sorry, I'm not using -current), I took a quick stab
at the problem (having dealt with XEmacs undump issues in a past life),
but I haven't gotten anywhere, yet:
Well, the problem appears to be that undump() isn't properly
adjusting the ELF section headers. The bug also seems to exist in
XEmacs (and probably GNU Emacs as well), but it's only triggered if a
small section (less than 32 bytes in size) exists before the BSS
section. Hacky, ugly, not-for-public-consumption kludgy patch attached.
Apply in the o subdirectory. Line numbers will be off, but the patch
should apply fine otherwise. Due to non-functioning makefile
dependencies, you'll have to manually delete o/unixsave.o (or do a
make clean) after applying this patch.
I'm not sure if the patch is 100% correct, but it should be close.
I probably won't have any more time to clean up the patch (e.g.,
eliminate the code duplication and debugging code), and so it would be
nice if someone else could do that and submit it.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
*** unexelf.c.orig Thu Mar 22 14:54:58 2001
--- unexelf.c Wed Apr 3 21:48:40 2002
***
*** 935,944
= OLD_SECTION_H (old_bss_index-1).sh_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#else
if (round_up (NEW_SECTION_H (nn).sh_offset,
OLD_SECTION_H (old_bss_index).sh_addralign)
! = new_data2_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#endif
/* Any section that was originally placed after the section
header table should now be off by the size of one section
--- 948,972
= OLD_SECTION_H (old_bss_index-1).sh_offset)
NEW_SECTION_H (nn).sh_offset += new_data2_size;
#else
+ # if 1
+ if (round_up (NEW_SECTION_H (nn).sh_offset,
+ OLD_SECTION_H (nn).sh_addralign 0 ? OLD_SECTION_H
+(nn).sh_addralign : 1) == new_data2_offset OLD_SECTION_H(nn).sh_size 0 ||
+ round_up (NEW_SECTION_H (nn).sh_offset,
+ OLD_SECTION_H (nn).sh_addralign 0 ? OLD_SECTION_H
+(nn).sh_addralign : 1)
+ new_data2_offset) {
+ # else
if (round_up (NEW_SECTION_H (nn).sh_offset,
OLD_SECTION_H (old_bss_index).sh_addralign)
! = new_data2_offset) {
! # endif
! # ifdef DEBUG
! fprintf(stderr,
! Rounding up section %d, old: 0x%08x, new: 0x%08x\n,
! nn, NEW_SECTION_H (nn).sh_offset,
! NEW_SECTION_H (nn).sh_offset + new_data2_size);
! # endif
NEW_SECTION_H (nn).sh_offset += new_data2_size;
+ }
#endif
/* Any section that was originally placed after the section
header table should now be off by the size of one section
Re: rtld messing up?
In article [EMAIL PROTECTED], Terry Lambert [EMAIL PROTECTED] wrote: John Polstra wrote: All I know is this: The dynamic linker was working just fine for years. Then we got a new version of binutils, and lots of problems started happening. The dynamic linker wasn't changed -- binutils was. I have no idea what got broken, but I kind of doubt that the bug is in the dynamic linker. The new binutils screws over some basic long-standing assumptions about field ordering and associativity in the object files, which are no longer maintained (for whatever reason) in the new version of the tools. Some of them have been identified and repaired (e.g. the Alpha code changes for the section/segment order assumption), but it is going to probably be a long battle. Technically, the ELF spec permits the ordering, so the assumptions are really broken, even though they code for what's really a defacto-standard of many years, now. 8-(. Can you be more specific? To the best of my knowledge, I made no assumptions beyond what the spec promised. The only exception is that the dynamic linker relies on the program header being in the first page of the file, an assumption shared by the kernel as well. I don't think that assumption is wrong, or nothing would run at all. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rtld messing up?
Technically, the ELF spec permits the ordering, so the assumptions are really broken, even though they code for what's really a defacto-standard of many years, now. 8-(. Can you be more specific? To the best of my knowledge, I made no assumptions beyond what the spec promised. The only exception is that the dynamic linker relies on the program header being in the first page of the file, an assumption shared by the kernel as well. I don't think that assumption is wrong, or nothing would run at all. I'm going to sound like a prat here, mostly because I don't know what I'm talking about. :-) In ports/lang/gcl, a program is undumped, and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. Could you please try that port, and see what you can glean? I'm frobbing around in xemacs, which works, to see if I can't fix undump. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rtld messing up?
On Wed, Mar 20, 2002 at 05:47:32PM +, Mark Murray wrote: In ports/lang/gcl, a program is undumped, and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. I've also have had that same problem when I tried to build the port, but was never able to find the reason for the program to segfault, I even opened a PR on that. The program seems to work on NetBSD btw. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg36393/pgp0.pgp Description: PGP signature
Re: rtld messing up?
In ports/lang/gcl, a program is undumped, and the resultant binary dumps core _very_ early in the startup. I can't get debugging info, because the undumping also seems to strip the program. I've also have had that same problem when I tried to build the port, but was never able to find the reason for the program to segfault, I even opened a PR on that. The program seems to work on NetBSD btw.=20 PR ports/34661 :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rtld messing up?
In article [EMAIL PROTECTED], Mark Murray [EMAIL PROTECTED] wrote: Here is kaffe (from ports) post mortem after an at-load blowup. #0 0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0) at /usr/src/libexec/rtld-elf/i386/reloc.c:196 196 *where += (Elf_Addr) obj-relocbase; (gdb) where #0 0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0) at /usr/src/libexec/rtld-elf/i386/reloc.c:196 #1 0x2804fb30 in relocate_objects (first=0x28064000, bind_now=0 '\000') at /usr/src/libexec/rtld-elf/rtld.c:1398 #2 0x2804e663 in _rtld (sp=0xbfbffa58, exit_proc=0xbfbffa50, objp=0xbfbffa54) at /usr/src/libexec/rtld-elf/rtld.c:380 Other ports (like QT2) are also doing this. Any ideas? All I know is this: The dynamic linker was working just fine for years. Then we got a new version of binutils, and lots of problems started happening. The dynamic linker wasn't changed -- binutils was. I have no idea what got broken, but I kind of doubt that the bug is in the dynamic linker. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rtld messing up?
John Polstra wrote: All I know is this: The dynamic linker was working just fine for years. Then we got a new version of binutils, and lots of problems started happening. The dynamic linker wasn't changed -- binutils was. I have no idea what got broken, but I kind of doubt that the bug is in the dynamic linker. The new binutils screws over some basic long-standing assumptions about field ordering and associativity in the object files, which are no longer maintained (for whatever reason) in the new version of the tools. Some of them have been identified and repaired (e.g. the Alpha code changes for the section/segment order assumption), but it is going to probably be a long battle. Technically, the ELF spec permits the ordering, so the assumptions are really broken, even though they code for what's really a defacto-standard of many years, now. 8-(. I hate the new binutils, but they are required for support for the 64 bit architectures, so they are not going to just go away. I think retrofitting support for these architectures into the old binutils would be a mistake. It's a little sad, since with the assumptions, the code would have been faster on initial execution, than without them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rtld messing up?
Hi Here is kaffe (from ports) post mortem after an at-load blowup. #0 0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0) at /usr/src/libexec/rtld-elf/i386/reloc.c:196 196 *where += (Elf_Addr) obj-relocbase; (gdb) where #0 0x280520ee in reloc_non_plt (obj=0x28064500, obj_rtld=0x280604a0) at /usr/src/libexec/rtld-elf/i386/reloc.c:196 #1 0x2804fb30 in relocate_objects (first=0x28064000, bind_now=0 '\000') at /usr/src/libexec/rtld-elf/rtld.c:1398 #2 0x2804e663 in _rtld (sp=0xbfbffa58, exit_proc=0xbfbffa50, objp=0xbfbffa54) at /usr/src/libexec/rtld-elf/rtld.c:380 Other ports (like QT2) are also doing this. Any ideas? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf #text/plain; name=cv.txt [Mark Murray CV Plain Text] cv.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
