Bug 28054

Summary: SEC_ELF_OCTETS not set for ".debug_*" sections causing invalid relocs for targets with OCTETS_PER_BYTE > 1
Product: binutils Reporter: Tucker <tuckkern+sourceware>
Component: gasAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: nickc
Priority: P2    
Version: 2.34   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: Possible patch that sets the flags in obj_elf_change_section

Description Tucker 2021-07-04 15:43:53 UTC
Created attachment 13535 [details]
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.
Comment 1 Sourceware Commits 2021-07-12 16:14:34 UTC
The master branch has been updated by Nick Clifton <nickc@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ef744040b49e92ecd3de3ae3b94c8f85020111c3

commit ef744040b49e92ecd3de3ae3b94c8f85020111c3
Author: Tucker <tuckkern@sourceware@gmail.com>
Date:   Mon Jul 12 17:12:13 2021 +0100

    Add the SEC_ELF_OCTETS flag to debug sections created by the assembler.
    
            PR 28054
    gas     * config/obj-elf.c (obj_elf_change_section): Set the
            SEF_ELF_OCTETS flag on debug sections.
Comment 2 Nick Clifton 2021-07-12 16:26:23 UTC
Hi Tucker,

  I have applied half of your patch.  During testing I found that setting
  the SEC_DEBUGGING flag causes binutils testsuite regressions for the FT32
  and MSP430 targets.  I am not entirely sure why, but I suspect that it
  is because these targets then start generating relocs to set values in
  the .debug_info and .debug_line sections, and these relocs are either 
  wrong, or not implemented properly.

  So I have applied the part that sets SEC_ELF_OCTETS, but not the part
  that sets SEC_ELF_DEBUGGING.

  One day, in my copious free time, I will investigate the SEC_DEBUGGING
  issue further. :-)

Cheers
  Nick
Comment 3 Tucker 2021-07-13 14:49:04 UTC
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
Comment 4 Tucker 2021-11-27 16:29:37 UTC
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
Comment 5 Nick Clifton 2021-11-29 13:21:11 UTC
(In reply to Tucker from comment #4)
> What regressions were you running on the FT32 & MSP430 targets?

I was using toolchains configured as ft32-elf and as nsp430-elf

> I tried
> adding back the SEC_DEBUGGING flag to debug this issue but I didn't notice
> any failures with "make check".

Were you looking at the binutils testsuite ?  The gas testsuite does not show any new failures, but the binutils testsuite does.  For example, for the ft32-elf toolchain I get:

FAIL: objdump compress debug sections
FAIL: objdump compress debug sections 3
FAIL: objcopy compress debug sections in archive with zlib-gabi
FAIL: objdump compress debug sections 3 with zlib-gabi
FAIL: unordered .debug_info references to .debug_ranges
FAIL: objdump -W
FAIL: objdump -W for debug_ranges
FAIL: follow-debuglink (--process-links --dwarf=info --dwarf=str)
FAIL: binutils-all/pr26548
FAIL: readelf -Wwi pr26548e (reason: unexpected output)
FAIL: readelf --debug-dump=loc locview-1 (reason: unexpected output)
FAIL: readelf --debug-dump=loc locview-2 (reason: unexpected output)
FAIL: readelf -wiaoRlL dw5
FAIL: readelf -wi dwarf-attributes (reason: unexpected output)
FAIL: readelf -wKis -P debuglink (reason: unexpected output)
FAIL: readelf --debug-dump=links --debug-dump=no-follow-links dwo

Cheers
  Nick
Comment 6 Nick Clifton 2021-11-29 13:25:32 UTC
(In reply to Nick Clifton from comment #5)
> I was using toolchains configured as ft32-elf and as nsp430-elf

Err, of course I meant "msp430-elf" not "nsp430-elf"....