https://sourceware.org/bugzilla/show_bug.cgi?id=33684

--- Comment #14 from Ali Bahrami <ali_swbugzilla at emvision dot com> ---
Comment on attachment 16497
  --> https://sourceware.org/bugzilla/attachment.cgi?id=16497
A patch

I dropped the patch on top of the binutils we build
for Solaris, and it seems to solve the issue.

I do not understand why this was not necessary on sparc.

The one difference I now see between foo.so and foo_copy.so
is that the index of the symtab section header has moved
down from it's previous position (18) to (21). This is
consistent with what happens when one deletes a section,
and then adds one. It would be a nice touch to instead
rewrite the existing section. One nice side effect of that
is that there is then no reason to rewrite any string tables.

I do not think you need to do that for this bug, as it does
not break the symbol sort sections (and I note that the
sh_link on those sections was updated properly). It's just
a thing I noticed while looking. I'll show the elfdiff output
for this below, in case it's of interest. Note that all the
differences are due only to the .symtab section index moving.

-----
% elfdiff foo.so foo_copy.so 
*** section: [18 <> 21].symtab: shdr information differs
<     sh_offset:    0x8f8               sh_entsize: 0x18 (37 entries)
>     sh_offset:    0x950               sh_entsize: 0x18 (37 entries)
---
<     sh_link:      19                  sh_info:    28
>     sh_link:      22                  sh_info:    28
*** section: [18 <> 21].symtab: data information differs
<     0x1c8:   [19]         0    0  SECT LOCL  D    0 .symtab            
(section index differs: 0)
>     0x1c8:   [19]         0    0  SECT LOCL  D    0 .symtab             
> (section index differs: 0)

*** section: [19 <> 22].strtab: shdr information differs
<     sh_offset:    0xc70               sh_entsize: 0
>     sh_offset:    0xcc8               sh_entsize: 0
*** section: [19 <> 22].strtab: data information differs
<     0x1:     f   o   o   .   s   o  \0   h   e   l   l   o   .   c  \0   _
>     0x1:     f   o   o   .   s   o  \0   _   E   N   D   _  \0   _   S   T

*** section: [20 <> 18].SUNW_symtabsort: shdr information differs
<     sh_offset:    0xcf0               sh_entsize: 0x4 (6 entries)
>     sh_offset:    0x8f8               sh_entsize: 0x4 (6 entries)
---
<     sh_link:      18                  sh_info:    0
>     sh_link:      21                  sh_info:    0

*** section: [21 <> 19].SUNW_symtabnsort: shdr information differs
<     sh_offset:    0xd08               sh_entsize: 0x4 (10 entries)
>     sh_offset:    0x910               sh_entsize: 0x4 (10 entries)
---
<     sh_link:      18                  sh_info:    0
>     sh_link:      21                  sh_info:    0

*** section: [22 <> 20].comment: shdr information differs
<     sh_offset:    0xd30               sh_entsize: 0x1 (19 entries)
>     sh_offset:    0x938               sh_entsize: 0x1 (19 entries)

*** section: [23].shstrtab: shdr information differs
<     sh_offset:    0xd43               sh_entsize: 0
>     sh_offset:    0xd45               sh_entsize: 0
*** section: [23].shstrtab: data information differs
<     0x0:    \0   .   d   y   n   a   m   i   c  \0   .   e   h   _   f   r
>     0x0:    \0   .   s   y   m   t   a   b  \0   .   s   t   r   t   a   b

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Reply via email to