Re: [FWD] compiling emacs-bidi,

> Date: Sun, 14 Mar 2004 22:15:03 -0800 (PST)
> From: rs6233 <[email protected]>
> 
> The program dumps core on line 925 of unexelf.c (in
> function unexec):
> 
> memcpy (NEW_SECTION_H (nn).sh_offset + new_base,
>                   (caddr_t) OLD_SECTION_H (n).sh_addr,
>                   new_data2_size);
> 
> The definitions in the beginning of unexelf.c are:
> 
> #define OLD_SECTION_H(n) \
>      (*(ElfW(Shdr) *) ((byte *) old_section_h +
> old_file_h->e_shentsize * (n)))
> 
> #define NEW_SECTION_H(n) \
>      (*(ElfW(Shdr) *) ((byte *) new_section_h +
> new_file_h->e_shentsize * (n)))
> 
> 
> When I am in gdb at the unexec level, I get:
> (gdb) print n
> $14 = 20
> (gdb) print nn
> $15 = 20
> (gdb) print new_section_h
> $16 = (Elf32_Shdr *) 0xbee98a18
> (gdb) print new_file_h
> No symbol "new_file_h" in current context.
> (gdb) print new_base
> $17 = 0xbd6d5000 "\177ELF\001\001\001"
> (gdb) print old_section_h
> $18 = (Elf32_Shdr *) 0xbf34edb8
> (gdb) print old_file_h
> No symbol "old_file_h" in current context.
> (gdb) print new_data2_size
> $20 = 20204640
> 
> Any ideas? Thanks.

We need to see the results of the following GDB commands:

 (gdb) print (*(ElfW(Shdr) *) ((byte *) old_section_h + old_file_h->e_shentsize * (n))).sh_addr

 (gdb) print (*(ElfW(Shdr) *) ((byte *) new_section_h + new_file_h->e_shentsize * (nn))).sh_offset

If these expressions yield an error message from GDB saying that there
are no symbols old_file_h and new_file_h in the current context, it's
possible that these two variables are stored in registers.  The
command "info address old_file_h" will tell you where it is stored,
and you could then replace the variables by their values.

Also, does new_data2_size look reasonable?  That is, is it less or
more than the size of the Emacs executable?  The number looks very
large (btw, is the value printed in decimal or in hex?).