GNU bug report logs -
#22061
24.5; Build failure on sparc64, Bus Error in src/unexelf.c
Previous Next
Reported by: David Matthew Mattli <dmm <at> mattli.us>
Date: Mon, 30 Nov 2015 16:32:03 UTC
Severity: important
Found in version 24.5
Fixed in version 25.1
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Looking at it some more I think I have a better understanding of what's
going on in the git master sources.
The SIGBUS occurs when accessing the pointer calculated with the
NEW_SECTION_H macro:
static void *
entry_address (void *section_h, ptrdiff_t idx, ptrdiff_t entsize)
{
char *h = section_h;
return h + idx * entsize;
}
#define NEW_SECTION_H(n) \
(*(ElfW (Shdr) *) entry_address (new_section_h, n,
new_file_h->e_shentsize))
This should generate aligned addresses, assuming 'new_section_h' is
aligned because it's adding multiples of 'new_file_h->e_shentsize' which
is 64. However new_section_h is /not/ aligned so the output of the macro
is also unaligned.
(gdb) print new_section_h
$27 = (Elf64_Shdr *) 0xffff800114f76933
(gdb) print (unsigned long)new_section_h % 8
$28 = 3
The variable 'new_section_h' is assigned on line 380:
new_section_h = (ElfW (Shdr) *) ((byte *) new_base +
new_file_h->e_shoff);
So its the sum of new_base and 'new_file_h->e_shoff'. new_base is highly
aligned so the problem must be 'new_file_h->e_shoff'
(gdb) print new_base
$29 = (caddr_t) 0xffff800112ca8000 "\177ELF\002\002\001"
(gdb) print new_file_h->e_shoff
$30 = 36497715
In turn, 'new_file_h->e_shoff' s misalignment comes from when
new_data2_size is added to it on line 377.
if (new_file_h->e_shoff >= old_bss_offset)
new_file_h->e_shoff += new_data2_size;
Finally the value of new_data2_size is calculated on line 334:
new_data2_size = new_bss_addr - old_bss_addr;
(gdb) print (unsigned long)(new_data2_size) % 8
$39 = 3
Because 'new_data2_size' is eventually added to 'new_section_h' it needs
to be aligned or 'new_section_h' has to be padded to a multiple of 8.
I think the easiest thing to do would be to round 'new_data2_size' to
the nearest multiple of 8.
This bug report was last modified 9 years and 178 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.