Re: [FWD] compiling emacs-bidi,

Hi,

Thanks again for your reply. Below is some more gdb
output based on your feedback.  new_data2_size value
is less than the emacs executable. However, everytime
I run the program, I get a different value for 
new_data2_size even though the program stop at the
same point.

(gdb) print (*(ElfW(Shdr) *) ((byte *) old_section_h +
old_file_h->e_shentsize * (n))).sh_addr
No symbol "ElfW" in current context.
(gdb) info address old_file_h
Symbol "old_file_h" is a field of the local class
variable `this'
(gdb) print new_data2_size
$5 = 26803296

Rafi

--- Eli Zaretskii <[email protected]> wrote:
> > 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?).
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com