Re: copy_private_bfd_data in bfd/elf.c question

[Andreas Schwab <schwab@suse.de>]

Steve Ellcey <sje@cup.hp.com> writes:

|> > How about posting before/after output of readelf -S -l, so we can
|> > have a clue as to what is going on.
|> 
|> Ok, here is an example (on IA64 HP-UX) of using strip on a small
|> executable where the executable coredumps after being stripped.  This is
|> using the standard binutils without our local changes to
|> copy_private_bfd_data.
|> 
|> [hpadl731] $ cat x.c
|> main ()
|> {
|>         printf("hi\n");
|> }
|> [hpadl731] $ gcc x.c -o x
|> [hpadl731] $ ./x
|> hi
|> [hpadl731] $ readelf -S -I x
|> There are 33 section headers, starting at offset 0x1778:
|> 
|> Section Headers:
|>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
|>   [ 0]                   NULL            00000000 ffffffff 000000 00      0   0  0
|>   [ 1] .dynamic          DYNAMIC         04000178 000178 0000b8 08   A  0   0  8
|>   [ 2] .dynsym           DYNSYM          04000230 000230 0001a0 10   A  3   0  8
|>   [ 3] .dynstr           STRTAB          040003d0 0003d0 00024a 00   A  0   0  1
|>   [ 4] .hash             HASH            04000620 000620 0000a4 00   A  0   0  8
                                                     ^^^^^^

[...]
|> [hpadl731] $ strip x
|> [hpadl731] $ ./x
|> Memory fault(coredump)
|> [hpadl731] $ readelf -S -I x
|> 
|> There are 31 section headers, starting at offset 0x11e4:
|> 
|> Section Headers:
|>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
|>   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
|>   [ 1] .dynamic          DYNAMIC         04000178 000178 0000b8 08   A  3   0  8
|>   [ 2] .dynsym           DYNSYM          04000230 000230 0001a0 10   A  3   0  8
|>   [ 3] .dynstr           STRTAB          040003d0 0003d0 00024a 00   A  0   0  1
|>   [ 4] .hash             HASH            04000620 00061c 0000a4 04   A  2   0  8
                                                     ^^^^^^

This seems to be the culprit.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."