8

Is it possible to write something like .finished$: instead of 1$: and this label would still be only valid until the next not-local label is defined?

That way it would be much more descriptive and I would still know after months why this is there. Of course I just could write a comment next to it, but this would be (at least for me) a bit laborious.

Jean-François Fabre
  • 137,073
  • 23
  • 153
  • 219

1 Answers1

2

Yes, it is. What you've indicated (.finished$) works perfectly.

EDIT: Well, I was completely wrong. Sorry for misleading people looking for answers.

From what I understand of your question, you need local labels in GNU as. As far as I know, that's not possible.

Label collisions are only found in the same source file. If you separated every function (which is the only situation this can fix) from the original source file, then it would work. If they're all within one function, you're done. This seems to be the best and most manageable solution from pure assembly.

Otherwise, you could use local symbols (not labels, see comments) like .L<function_id>_<local_label>, where the .L ensures that it's file-local, but I generally dislike it. It does, however, require extra typing.

In case, however, you can do most of the work in C and use the GNU extended assembler, the GNU extended assembly page notes that within the AssemblyTemplate, you have this option:

Special format strings
[...]
'%='
Outputs a number that is unique to each instance of the asm statement in the entire compilation. This option is useful when creating local labels and referring to them multiple times in a single template that generates multiple assembler instructions.

From that, you could use labels like .%=labelname: from within GNU inline assembler and it will be work. Even then, what are you trying to accomplish? There is probably a better way somewhere.

ARaspiK
  • 155
  • 10
  • I apologise. I've fixed it, and included the relevant information. – ARaspiK May 27 '18 at 19:27
  • 1
    Your answer improved significantly, so I retracted my decision. – zx485 May 27 '18 at 20:17
  • 1
    @zx485: but it's still wrong: `as` only supports dollar local labels on some targets, not including x86. The TIGCC docs are only talking about [that port of gcc](http://tigcc.ticalc.org/about.html) for TI-89 / TI-92+ calculators. The mainline GAS manual (https://sourceware.org/binutils/docs/as/Symbol-Names.html) says dollar local labels, on targets that support them, use a colon after the dollar, not *instead* of the dollar. And in any case it only works for numbered local *labels*. You can have file-scope local *symbol* names (like `.Lfoo`), but only numbered local *labels*. – Peter Cordes May 28 '18 at 00:47
  • 1
    TL:DR: `.finished$:` assembles for x86, but it's just an ordinary symbol name that contains a dollar sign. And if you use it twice in one file, it's an error, like `func1: .finished$` / `func2: .finished$`. e.g. `Error: symbol '.finished$' is already defined` – Peter Cordes May 28 '18 at 00:49
  • 1
    And `.finished$` without the `:` doesn't assemble: `Error: unknown pseudo-op: '.finished$'` – Peter Cordes May 28 '18 at 01:05
  • I'm sorry. I completely messed up. Now, I've looked over the docs, and there's no real answer I can find. I've posted my own workarounds and I hope they're of some help. – ARaspiK May 28 '18 at 05:12
  • 1
    BTW, you should recommend `.Lfinished:` (a local *symbol* name, won't appear in the `.o`). It still has file scope, but this is why `gcc -S` output uses `.L0`, `.L1`, etc. label names. – Peter Cordes May 28 '18 at 06:15
  • Thanks @PeterCordes! Added it to my answer. – ARaspiK May 28 '18 at 07:01
  • GNU C local labels is just getting way off topic, and you should remove that part. (Note that `__label__ label1;` is a GNU extension, but at least it's portable to any target. Hopefully that's what you meant by "normal C"). This is an assembly question, so even suggesting using GNU C inline asm with a separate `asm("")` block for each function is a stretch. (If you've read my answers, you'll know they're full of side-notes and related stuff, but GNU C local labels aren't even *related* to GAS local labels or local symbol names. Two very different languages.) – Peter Cordes May 28 '18 at 07:12
  • And BTW, putting comments on numbered labels only helps at the label side, not at any of the jumps that go there. For me, it's not an issue of commenting labels being "too much work", it's that meaningful label names make it easier to follow the logic of the `jcc` and `jmp` instructions that go there from various places. Like `je .Lreturn` is clearly the end of the function, not just a `break` out of one level of nested loops. If it was `je 4f`, you'd have to go check which label that was. You should use almost always use named labels, with commented numbered (local) labels only for macros. – Peter Cordes May 28 '18 at 07:16
  • @PeterCordes: About the C local labels - I get your point, I'll fix that - about the numbered labels - The number only changes with different `asm("")` calls, so calling from within the same `asm` block is not a problem. Outside that, it doesn't even work. – ARaspiK May 28 '18 at 10:01
  • I wasn't talking about autonumbered inside GNU C inline asm, I was talking about what GAS calls "local labels" i.e. `1: dec %ecx; jnz 1b` where the name can only include digits, vs. what GAS calls "local *symbols*", i.e. `.Lloop: dec %ecx; jnz .Lloop`. Inside an `asm("")` statement, yeah you can reuse `.Lloop%=:` inside different asm statements. The main reason that feature exists is so a statement can inline in more than one place without causing multiple-definition errors. (e.g. function inlining, loop unrolling, or tail-duplications optimizations.) – Peter Cordes May 28 '18 at 10:04
  • Okay, I understand now. Everything about numbered labels is bad and they should be destroyed, unless the compiler is generating them and nobody has to read through the asm (hah, right. We all do for debugging. Addresses are still horrible). Also, I never actually mentioned GAS local labels. I'll edit my answer to ensure that's not ignored. – ARaspiK May 28 '18 at 10:10
  • You didn't mention GAS local labels, but *the question is about them*: i.e. looking for an alternative to `1:` or `1$:` GAS local label naming requirements that the name be entirely digits. They're useful in macros, because `1f` vs. `1b` refers to the nearest label in forward or backward direction, so a macro definition can include a label without causing problems if used more than once. Other than that, they're horrible. And it would be nice if multiple functions in the same file could have their own `.Ldone:` label. – Peter Cordes May 28 '18 at 10:25
  • Label names like `1:` aren't always terrible if they're close to the `je 1f` that targets them and the branching is simple. (And you can't think of a useful meaningful name.) My earlier comments were slightly too harsh / general. – Peter Cordes Dec 28 '22 at 04:56