[Bug ld/26543] New: bfd_generic_define_common_symbol does not calculate correct alignment when bfd_octets_per_byte > 1 and power_of_two == 0
https://sourceware.org/bugzilla/show_bug.cgi?id=26543 Bug ID: 26543 Summary: bfd_generic_define_common_symbol does not calculate correct alignment when bfd_octets_per_byte > 1 and power_of_two == 0 Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: minor Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: tuckkern+sourceware at gmail dot com Target Milestone: --- Created attachment 12803 --> https://sourceware.org/bugzilla/attachment.cgi?id=12803&action=edit Patch implementing described fix bfd_generic_define_common_symbol does not calculate the correct alignment for targets with more than 1 octet per byte if alignment power is less than 1. 3103: linker.c alignment = bfd_octets_per_byte (output_bfd, section) << power_of_two; e.g. A target has 16-bit bytes and an alignment of 1 byte (2 octets). A common variable may be defined as .comm variable,1,1 bfd_log2(1) will calculate alignment_power == 0 Mathematically 2 ** 0 == 1 which would be correct but the above statement will evaluate to 2. Instead the statement should check for a power_of_two == 0 condition i.e. alignment = power_of_two ? bfd_octets_per_byte (output_bfd, section) << power_of_two : 1; -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26543] bfd_generic_define_common_symbol does not calculate correct alignment when bfd_octets_per_byte > 1 and power_of_two == 0
https://sourceware.org/bugzilla/show_bug.cgi?id=26543 --- Comment #3 from Tucker --- Nick, No problem. Thanks for the quick response! -Tucker -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] New: relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 Bug ID: 26556 Summary: relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1 Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: minor Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: tuckkern+sourceware at gmail dot com Target Milestone: --- Created attachment 12810 --> https://sourceware.org/bugzilla/attachment.cgi?id=12810&action=edit Possible patch The case statement handling rs_org in write.c around line 2937 does not appear to calculate the correct target fragment address when OCTETS_PER_BYTE > 1 It only applies OCTETS_PER_BYTE scaling to the symbol value, but not the offset. The end result is symbols in .bss with overlapping addresses. e.g. from readelf - array_ has a size of 4, but var_ is located at address 2 Num:Value Size TypeBind Vis Ndx Name 5: 4 OBJECT LOCAL DEFAULT4 array_ 6: 0002 1 OBJECT LOCAL DEFAULT4 var_ The attached patch is a possible fix, but II am unsure if this is the correct place to address the issue or if there is another root cause. Using the above patch the symbol table now looks like so: Num:Value Size TypeBind Vis Ndx Name 5: 4 OBJECT LOCAL DEFAULT4 array_ 6: 0004 1 OBJECT LOCAL DEFAULT4 var_ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 --- Comment #2 from Tucker --- Created attachment 12846 --> https://sourceware.org/bugzilla/attachment.cgi?id=12846&action=edit Minimal example showcasing problem -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 --- Comment #3 from Tucker --- Sure thing Nick. I've attached some assembly that showcases the issue. To reproduce, build a target with OCTETS_PER_BYTE_POWER set to 1. I choose MSP430 as a victim. Normal MSP430: Num:Value Size TypeBind Vis Ndx Name 5: 4 OBJECT LOCAL DEFAULT3 array_ 6: 0004 1 OBJECT LOCAL DEFAULT3 var_ OCTETS_PER_BYTE_POWER = 1 MSP430: Num:Value Size TypeBind Vis Ndx Name 5: 4 OBJECT LOCAL DEFAULT3 array_ 6: 0002 1 OBJECT LOCAL DEFAULT3 var_ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 --- Comment #5 from Tucker --- Hi Nick, Thanks for the information regarding tic54x-coff and gas/org-3 test. I will re-investigate the issue with this target in mind. Regarding the target: Yes, this is a new ELF target with 16 bit bytes I've been experimenting with. The legacy tool-chain is horrific, and I've been trying to get better tools functioning on it as a side project. -Tucker -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26556] relax_segment calculates incorrect target frag when OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=26556 Tucker changed: What|Removed |Added Attachment #12810|0 |1 is obsolete|| --- Comment #6 from Tucker --- Created attachment 12848 --> https://sourceware.org/bugzilla/attachment.cgi?id=12848&action=edit Patch the offset in bss_alloc instead Nick, Traced the source of fr_offset back to bss_alloc. Applying the octet adjustment here seems to fix the issues as well as keep the org test cases happy. Just food for thought. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28054] New: SEC_ELF_OCTETS not set for ".debug_*" sections causing invalid relocs for targets with OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=28054
Bug ID: 28054
Summary: SEC_ELF_OCTETS not set for ".debug_*" sections causing
invalid relocs for targets with OCTETS_PER_BYTE > 1
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: tuckkern+sourceware at gmail dot com
Target Milestone: ---
Created attachment 13535
--> https://sourceware.org/bugzilla/attachment.cgi?id=13535&action=edit
Possible patch that sets the flags in obj_elf_change_section
For targets where OCTETS_PER_BYTE > 1, invalid relocs & fixups are generated in
the DWARF2 ".debug_*" sections because SEC_ELF_OCTETS is not set when these
sections are created.
Since SEC_ELF_OCTETS is not set various functions do not compute proper offset
and addresses in these sections. e.g. bfd_octets_per_byte, frag_now_fix,
resolve_symbol_value, bfd_install_relocation, bfd_perform_relocation.
Currently the only place this flag is set is in
_bfd_elf_make_section_from_shdr.
Attached is a patch that mimics the code from _bfd_elf_make_section_from_shdr
in obj_elf_change_section to ensure these flags are set.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/28054] SEC_ELF_OCTETS not set for ".debug_*" sections causing invalid relocs for targets with OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=28054 --- Comment #3 from Tucker --- Hi Nick, Thanks for the quick action. Ah, maybe I can take a look at those regressions for you. A cursory looks tells me it's likely in FT32's "relaxable_section" function which appears to kick out any sections marked as SEC_DEBUGGING. For MSP430, it's probably the implementation of TC_FORCE_RELOCATION_SUB_SAME which does a similar check for SEC_DEBUGGING. Either way, having SEC_ELF_OCTETS set properly lets me keep going. Thanks, Tucker -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28054] SEC_ELF_OCTETS not set for ".debug_*" sections causing invalid relocs for targets with OCTETS_PER_BYTE > 1
https://sourceware.org/bugzilla/show_bug.cgi?id=28054 --- Comment #4 from Tucker --- Hi Nick, What regressions were you running on the FT32 & MSP430 targets? I tried adding back the SEC_DEBUGGING flag to debug this issue but I didn't notice any failures with "make check". -Tucker -- You are receiving this mail because: You are on the CC list for the bug.
