This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: m68k (elf) gas dwarf problem


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]