m68k (elf) gas dwarf problem

Joel Sherrill joel.sherrill@OARcorp.com
Tue Apr 20 00:59:00 GMT 2004


Alan Modra wrote:

> On Fri, Apr 16, 2004 at 12:48:13PM -0500, Joel Sherrill <joel@OARcorp.com> wrote:
> 
>>s1.s:926: Error: unaligned opcodes detected in executable segment
>>
>>So adding the --gdwarf2 results in the unaligned error.
>>
>>Is this a bug or is something wrong with the assembly code?
> 
> 
> I'll tell you what is happening, and you can judge whether it's a bug or
> whether the assembly is invalid.  :)

I am willing to change the assembly so I think that means the bug
falls on this side of the line. :)

But I still don't understand how this code fragment is putting something
in the .text section.  It sure won't compile when it is a ds.b so I
buy that you nailed the reason but why?  Is this being treated as
constant data which can reside there?

.data
.align 4
_AsteccBusWidth: ds.w 1  <-- was ds.b
_AsteccCsSwitch: ds.w 1  <-- was ds.b
_AsteccCpuName: ds.l 1

And for safety, shouldn't I define the constants now as 0x0100 or
0x0101 so whatever code uses this will be happy?

> tc-m68k.h defines DWARF2_LINE_MIN_INSN_LENGTH to 2, because all m68k
> instructions are a multiple of 2 bytes long.  This allows dwarf2 address
> information to drop the redundant zero lsb, potentially allowing smaller
> debug info.  In your testcase, you emit single byte values to .text,
> breaking the assumption that anything in .text requiring address
> location info will be at an even address.

This turned out to be a pain.  There was a .ascii istring which had
to be increased by a byte.

It compiles now but I would like to understand the case above.

Thanks.

--joel




More information about the Binutils mailing list