This is the mail archive of the
mailing list for the binutils project.
Re: [RFC][ARM][AARCH64] Set DWARF2_LINE_MIN_INSN_LENGTH to 1
- From: Richard Henderson <rth at redhat dot com>
- To: Nicholas Clifton <nickc at redhat dot com>, Renlin Li <renlin dot li at arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Cc: Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Wed, 01 Apr 2015 12:51:28 -0700
- Subject: Re: [RFC][ARM][AARCH64] Set DWARF2_LINE_MIN_INSN_LENGTH to 1
- Authentication-results: sourceware.org; auth=none
- References: <55158759 dot 8090300 at arm dot com> <551C164D dot 4010103 at redhat dot com>
On 04/01/2015 09:01 AM, Nicholas Clifton wrote:
> Hi Renlin,
>> If any cases left the last frag unaligned(size of the frag) to
>> DWARF2_LINE_MIN_INSN_LENGTH, and assembled with -gdwarf-2 flag,
>> The following error will be triggered.
>> '''Error: unaligned opcodes detected in executable segment'''.
>> For the following code snippet;
>> .byte 0xf --> data in .text section, minimum size is different.
> I do not think that this is a bug. The assembler is correctly reporting that
> the user has created a code section that ends not on a code alignment
> boundary. It does appear however that this kind of thing is expected to work.
> (See eg gas/testsuite/gas/elf/section7.s). So maybe a solution is needed.
> Setting DWARF2_LINE_MIN_INSN_LENGTH to 1 seems wrong to me. For the normal
> case we want to use a dwarf insn length that matches the architecture's insn
> length. So instead, how about the attached patch? It changes the dwarf2dbg.c
> code so that it computes a maximum allowable value for
> DWARF2_LINE_MIN_INSN_LENGTH automatically, using the target supplied value as a
> starting point, but reducing it if necessary to support pathological assembly
> What do you think ?
I don't think we need any change at all.
I think the test case is just buggy.
Any real code would have .balign 4, or equivalent, to align the instructions.
Which would also add the required alignment padding at the end of the section,
covering any byte data in the constant pool.