hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs + glibc binary compatibility


From: Marcus Brinkmann
Subject: Re: emacs + glibc binary compatibility
Date: Sun, 28 Apr 2002 17:32:10 -0400
User-agent: Mutt/1.3.25i

On Sun, Apr 28, 2002 at 02:59:01PM -0400, Roland McGrath wrote:
> If that backtrace is correct, the problem starts at the beginning, with the
> wrong address for main passed to __libc_start_main.  Please start at the
> program's entry point (_start) and step through to see where things start
> to look wrong.

Ok, this is interesting.  I have traced the execution first until
the RETURN_TO invocation in sysdepds/mach_hurd/dl-sysdep.c
_dl_sysdep_start.  I can positively say that in

        RETURN_TO (argdata, &_dl_start_user, _dl_hurd_data->user_entry);

_dl_hurd_data->user_entry is the correct entry point as in the emacs
binary recorded:

objdump -x /bin/emacs:
/bin/emacs:     file format elf32-i386
/bin/emacs
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0804f258

The address 0x085f258, which is XMapRaised + 16, was in
_dl_hurd_data->user_entry (this is the address following the last
dynamic symbol, it seems, or shortly after that).

So, I stepped with nexti through RETURN_TO (sysdeps/mach/i386/sysdep.h),
and everything looked ok as far as I could see it.  Then RETURN_TO makes
it to _dl_start_user, which is in sysdeps/i386/dl-machine.h, and a macro
in assembler, evil (because gdb doesn't know how to follow the source,
at least I couldn't make it see it).  Anyway, this function did not
harm the reutn address in %edi, and correctly jumped to that function.

(gdb) nexti
0x0804f258 in XMapRaised ()
(gdb) x/20i $pc
0x804f258 <XMapRaised+16>:      xor    %ebp,%ebp
0x804f25a <XMapRaised+18>:      pop    %esi
0x804f25b <XMapRaised+19>:      mov    %esp,%ecx
0x804f25d <XMapRaised+21>:      and    $0xfffffff0,%esp
0x804f260 <XMapRaised+24>:      push   %eax
0x804f261 <XMapRaised+25>:      push   %esp
0x804f262 <XMapRaised+26>:      push   %edx
0x804f263 <XMapRaised+27>:      push   $0x81739f8
0x804f268 <XMapRaised+32>:      push   $0x804d6d0
0x804f26d <XMapRaised+37>:      push   %ecx
0x804f26e <XMapRaised+38>:      push   %esi
0x804f26f <XMapRaised+39>:      push   $0x80d5744
0x804f274 <XMapRaised+44>:      call   0x804efe8 <__libc_start_main>
0x804f279 <XMapRaised+49>:      hlt
0x804f27a <XMapRaised+50>:      mov    %esi,%esi
0x804f27c <XMapRaised+52>:      push   %ebp
0x804f27d <XMapRaised+53>:      mov    %esp,%ebp
0x804f27f <XMapRaised+55>:      push   %ebx
0x804f280 <XMapRaised+56>:      push   %eax
0x804f281 <XMapRaised+57>:      call   0x804f286 <XMapRaised+62>
(gdb) nexti
0x0804f25a in XMapRaised ()
(gdb)
0x0804f25b in XMapRaised ()

(more nextis)
0x0804f274 in XMapRaised ()
(gdb) nexti

Program received signal SIGSEGV, Segmentation fault.
0x012f7ba8 in ?? ()
(gdb)

So the main address in _libc_start_main is hard coded in the binary,
as 0x80d5744.  I don't have debugging symbols in the emacs binary,
would it be helpful to recompile it (against the old glibc)?
Or where does the above code come from?

Thanks,
Marcus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]