Can somebody help me understand what the heck is going on here? (ARM Cortex-M0)

When I assemble this simple blink program, it works flawlessly. When I remove line 22, all hell breaks loose.

As I understand it, .type directives are metadata only. So I diff the output of objdump between good and bad. You can see it's changing the pointer in my vector table by one. The disassembly of the bad one actually looks CORRECT though, because `main` starts at 0x10000108.

· · Web · 1 · 0 · 0

The good one on the left SHOULDN'T work because instructions need to be aligned, and 0x10000109 is not 2-byte aligned (Thumb), but somehow it does?

Why is the .type directive affecting my vector table at all?

My brain is cooked. 🤦

@winduptoy The LSB of the PC is 1 for Thumb mode. The bad one is trying to run Thumb instructions as full-length ARM instructions.

@winduptoy Guessing, from there: without the .type directive, the assembler treats `main` as data and not code, and so doesn't set the LSB because that would not be a thing for data.

@emily Ah, yes! Thank you! This makes sense but is completely unintuitive.

My code is in the .text section. I'm assembling with the `-mthumb` flag. My file has the .thumb directive up top. I have specified a Cortex-M0 processor that supports only Thumb. Apparently none of that is enough to just do the right thing! :sadlinux:

I quickly googled the .type directive and multiple people said "just for extra debugging context, not required." 🤷

@winduptoy The most fun debugging tools are the ones that make the bug magically disappear without changing any code.

(I agree, that's some bizarre asinine behavior)

Sign in to participate in the conversation

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.