What are .LX routine tags for in x86-64 asm?

I've tried searching for this online but I haven't found any answers for it. I'm studying the assembly conditional jumps and am working with this C routine:

long absdiff (long x, long y) {
	long result;

	if (x > y)
		result = x-y;
	else
		result = y-x;

	return result;
}

My notes say that it returns an asm code the likes of this one:

absdiff:
	cmpq %rsi, %rdi
	jle  .L4
	movq %rdi, %rax
	subq %rsi, %rax
	ret
.L4:
	movq %rsi, %rax
	subq %rdi, %rax
	ret

As I understand, the routine would jump to .L4 if x <= y and then return to the next instruction from that jump and continue until ret, which I know is wrong. Since %rax is written in .L4, I asume its ret works for the whole routine, not the one jumped to, but I've also seen this code more like this when debugging the C routine with gdb:

0x1119 <absdiff>     mov   %rdi,%rax
0x111c <absdiff+3>   cmp   %rsi,%rdi
0x111f <absdiff+6>   jle   0x1125 <absdiff+12>
0x1121 <absdiff+8>   sub   %rsi,%rax
0x1124 <absdiff+11>  retq
0x1125 <absdiff+12>  sub   %rdi,%rsi
0x1128 <absdiff+15>  mov   %rsi,%rax
0x112b <absdiff+18>  retq

Here I understand that the routine returns on different points just like you would write different returns on a C routine. So my question is: What's the meaning of .LX routine tags in assembly language and what relationship do have with the routine they are jumped to from?

The jle instruction performs a jump rather than a call. This transfers control directly, without pushing a return address onto the stack: it is like a goto in C, rather than like a call. That means that the following ret returns to absdiff's caller, since that's still the top return address on the stack.

The label names like .L4 are auto-numbered by the compiler, every time it wants a branch target.

Clang numbers its labels by counting basic blocks (so the 4th basic block in the first function will have a label name like .LBB0_3), but I think GCC only increments its label counter when it emits the (first) jump instruction that jumps there.

That's why the labels themselves aren't in strictly increasing numerical order within a function, only overall within a file.

GCC never jumps across function boundaries to these internal labels.

.Lname labels are local labels that don't go into the symbol table of the object file / executable. That's why you don't see them in the debugger, just the function names.

> I asume its ret works for the whole routine, not the one jumped to,

Yes. ret isn't magic. ret is just pop %rip. jne doesn't push a return address so it's not a function call, just a normal branch.

BTW, having two ways out of a function is called "tail duplication" optimization. Instead of having one path jump to the other, they both just do whatever cleanup and ret. Execution will go through one or the other, not both.

> but I've also seen this code more like this when debugging the C routine with gdb:

"but"? That's just what you get from assembling + linking the compiler-generated asm.

The symbolic named branch target is replaced (by the assembler in this case) with numeric target addresses. (Actually encoded as relative displacements, like jcc rel8.) The assembler is able to do it without waiting for link-time because the jump is in the same file as the target, and because it's relative.

one:
    b .L77
    nop
    nop
.L77:
    b two
    nop
    nop
two:
    b .three
    nop
    nop
    nop
.three:
    nop
    nop
    


Disassembly of section .text:

00000000 <one>:
   0:	ea000001 	b	c <one+0xc>
   4:	e1a00000 	nop			; (mov r0, r0)
   8:	e1a00000 	nop			; (mov r0, r0)
   c:	ea000001 	b	18 <two>
  10:	e1a00000 	nop			; (mov r0, r0)
  14:	e1a00000 	nop			; (mov r0, r0)

00000018 <two>:
  18:	ea000002 	b	28 <.three>
  1c:	e1a00000 	nop			; (mov r0, r0)
  20:	e1a00000 	nop			; (mov r0, r0)
  24:	e1a00000 	nop			; (mov r0, r0)

00000028 <.three>:
  28:	e1a00000 	nop			; (mov r0, r0)
  2c:	e1a00000 	nop			; (mov r0, r0)

the compiler generates assembly the assembly is fed to the assembler and turned into an object. The compiler will need to generate labels independent of the labels you created (function names, etc), so this particular one uses .Ln where n is a number in a way that it is unique within that assembly language program/module/file.

This assembler clearly keeps the other non .Ln labels in the binary/object but discards the .Ln labels. Then you use a separate tool a disassembler which chooses how it wants to represent the machine code. In this case we get an absolute address b c means b 0xC as well as a helper, 0xC is at the offset 0xC from one the nearest label. Clearly simply putting a dot in front of the label is not how to make it disappear.

but this

one:
    b .L77
    nop
    nop
.L77:
    b two
    nop
    nop
two:
    b .Lthree
    nop
    nop
    nop
.Lthree:
    nop
    nop
    

00000000 <one>:
   0:	ea000001 	b	c <one+0xc>
   4:	e1a00000 	nop			; (mov r0, r0)
   8:	e1a00000 	nop			; (mov r0, r0)
   c:	ea000001 	b	18 <two>
  10:	e1a00000 	nop			; (mov r0, r0)
  14:	e1a00000 	nop			; (mov r0, r0)

00000018 <two>:
  18:	ea000002 	b	28 <two+0x10>
  1c:	e1a00000 	nop			; (mov r0, r0)
  20:	e1a00000 	nop			; (mov r0, r0)
  24:	e1a00000 	nop			; (mov r0, r0)
  28:	e1a00000 	nop			; (mov r0, r0)
  2c:	e1a00000 	nop			; (mov r0, r0)

does make it disappear so one would assume that .Lx is a valid label name but the assembler does not put it in the symbol table of the output binary. The code is correct it just doesn't have all the labels the assembly language had which is fine, the machine code has no labels its only a human readable thing. This mechanism allows the toolchain to easily generate intermediate labels per file and not have to magically figure out how to avoid conflicts (wouldn't be possible).

This assembler (family, gnu assembler, gas) also has this feature which is not used by the compilers but by some lazy coders:

1:
    b 1f
    b 1b
    b 2f
1:
    nop
    nop
2:


00000000 <.text>:
   0:	ea000001 	b	c <.text+0xc>
   4:	eafffffd 	b	0 <.text>
   8:	ea000001 	b	14 <.text+0x14>
   c:	e1a00000 	nop			; (mov r0, r0)
  10:	e1a00000 	nop			; (mov r0, r0)

1f means label 1: forward in the code 1b means label 1 backward in the code (the first occurrence in that direction). you can use the same label name 1: or a small number of them 1: 2: 3: all through your code for the same purpose as .Lx but you don't even have to have unique labels. perhaps this works for something other than numbers I have not tried.