Support Arm dynamic linking

[DrXiao]

The proposed changes enhance shecc to generate dynamically linked executables. When the --dynlink flag is specified, shecc produces sections such as .plt and .got for the compiled programs, allowing the executables to leverage the ELF interpreter and the GNU C library to run.

This pull request is still a work in progress due to the following incomplete tasks:

• Fix the potential issues. (The bootstrapping process still fails for dynamically linked shecc.)
• Improve code quality and commit messages.
• Make the dynamically linked shecc run the test suites.
• Improve README.md to describe dynamic linking.
• Enhance GitHub workflows to verify the dynamically linked shecc.
• Validate the proposed changes on an Arm machine such as a BeagleBone Black or Raspberry Pi.
• Refine c.c and c.h to avoid duplications
• Update and separate the snapshots for static linking and dynamic linking.
• Add required documentation

Updated usage: (10/11 11:43 updated)

# Perform bootstrapping process for the dynamically linked shecc.
$ make DYNLINK=1

# Add '--dynlink' to generate dynamically linked executable.
$ shecc [-o output] [+m] [--dump-ir] [--no-libc] [--dynlink] <input.c>

# Run the generated executable by given the elf interpreter prefix.
$ qemu-arm -L /usr/arm-linux-gnueabihf/ <executable>

[DrXiao]

Currently, only the stage 0 compiler and stage 1 compiler can be generated, and the stage 1 compiler will encounter a Segmentation fault when running.

However, the stage 0 compiler can still compile a simple program and run the executable via QEMU:

/* test.c */
int main(void)
{
    printf("%x %x %x\n", 1, 2, 3);
    printf("%x %x %x %x\n", 1, 2, 3, 4);
    printf("%x %x %x %x %x\n", 1, 2, 3, 4, 5);
    return 0;
}

$ out/shecc --dynlink -o test test.c

Then, we can use arm-linux-gnueabi-readelf or arm-linux-gnueabi-objdump to check the executable. For example, check the relocation information:

$ arm-linux-gnueabi-readelf --relocs test

Relocation section '.rel.plt' at offset 0x260 contains 2 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
000102a8  00000116 R_ARM_JUMP_SLOT   00000000   __libc_start_main
000102ac  00000216 R_ARM_JUMP_SLOT   00000000   printf

However, I ran the test via qemu-arm and found that while the program can execute the main function, the result of certain printf() calls are incorrect.

$ qemu-arm -L /usr/arm-linux-gnueabi/ test
1 2 3
1 2 3 40830000
1 2 3 40830000 10224

Notice that the second and third printf() calls have more than four arguments, certain arguments will be pushed to the stack due to the Arm calling convention.

I think this is a potential issue that shecc pushes wrong values to the stack to make (glibc's) printf() calls produce incorrect results.

[DrXiao]

FWIW, I disassemble the test executable:

test.asm

$ arm-linux-gnueabi-objdump -d test

test:     file format elf32-littlearm


Disassembly of section .text:

000100b4 <.text>:
   100b4:	e3a0b000 	mov	fp, #0
   100b8:	e3a0e000 	mov	lr, #0
   100bc:	e49d1004 	pop	{r1}		@ (ldr r1, [sp], #4)
   100c0:	e1a0200d 	mov	r2, sp
   100c4:	e52d2004 	push	{r2}		@ (str r2, [sp, #-4]!)
   100c8:	e52d0004 	push	{r0}		@ (str r0, [sp, #-4]!)
   100cc:	e3a0c000 	mov	ip, #0
   100d0:	e52dc004 	push	{ip}		@ (str ip, [sp, #-4]!)
   100d4:	e30000ec 	movw	r0, #236	@ 0xec
   100d8:	e3400001 	movt	r0, #1
   100dc:	e3a03000 	mov	r3, #0
   100e0:	eb000067 	bl	0x10284
   100e4:	e3a0007f 	mov	r0, #127	@ 0x7f
   100e8:	eb000005 	bl	0x10104
   100ec:	e1a09000 	mov	r9, r0
   100f0:	e1a0a001 	mov	sl, r1
   100f4:	e3008004 	movw	r8, #4
   100f8:	e3408000 	movt	r8, #0
   100fc:	e04dd008 	sub	sp, sp, r8
   10100:	e1a0c00d 	mov	ip, sp
   10104:	eb000005 	bl	0x10120
   10108:	e3008004 	movw	r8, #4
   1010c:	e3408000 	movt	r8, #0
   10110:	e08dd008 	add	sp, sp, r8
   10114:	e1a00000 	nop			@ (mov r0, r0)
   10118:	e3a07001 	mov	r7, #1
   1011c:	ef000000 	svc	0x00000000
   10120:	e1a00009 	mov	r0, r9
   10124:	e1a0100a 	mov	r1, sl
   10128:	eaffffff 	b	0x1012c
   1012c:	e50de004 	str	lr, [sp, #-4]
   10130:	e3008044 	movw	r8, #68	@ 0x44
   10134:	e3408000 	movt	r8, #0
   10138:	e04dd008 	sub	sp, sp, r8
   1013c:	e3000224 	movw	r0, #548	@ 0x224
   10140:	e3400001 	movt	r0, #1
   10144:	e3a01001 	mov	r1, #1
   10148:	e3a02002 	mov	r2, #2
   1014c:	e3a03003 	mov	r3, #3
   10150:	e58d0004 	str	r0, [sp, #4]
   10154:	e58d1008 	str	r1, [sp, #8]
   10158:	e58d200c 	str	r2, [sp, #12]
   1015c:	e58d3010 	str	r3, [sp, #16]
   10160:	e59d0004 	ldr	r0, [sp, #4]
   10164:	e59d1008 	ldr	r1, [sp, #8]
   10168:	e59d200c 	ldr	r2, [sp, #12]
   1016c:	e59d3010 	ldr	r3, [sp, #16]
+  10170:	eb000046 	bl	0x10290
   10174:	e300022e 	movw	r0, #558	@ 0x22e
   10178:	e3400001 	movt	r0, #1
   1017c:	e3a01001 	mov	r1, #1
   10180:	e3a02002 	mov	r2, #2
   10184:	e3a03003 	mov	r3, #3
   10188:	e3a04004 	mov	r4, #4
   1018c:	e58d0014 	str	r0, [sp, #20]
   10190:	e58d1018 	str	r1, [sp, #24]
   10194:	e58d201c 	str	r2, [sp, #28]
   10198:	e58d3020 	str	r3, [sp, #32]
   1019c:	e58d4024 	str	r4, [sp, #36]	@ 0x24
   101a0:	e59d0014 	ldr	r0, [sp, #20]
   101a4:	e59d1018 	ldr	r1, [sp, #24]
   101a8:	e59d201c 	ldr	r2, [sp, #28]
   101ac:	e59d3020 	ldr	r3, [sp, #32]
   101b0:	e59d4024 	ldr	r4, [sp, #36]	@ 0x24
+  101b4:	eb000035 	bl	0x10290
   101b8:	e300023b 	movw	r0, #571	@ 0x23b
   101bc:	e3400001 	movt	r0, #1
   101c0:	e3a01001 	mov	r1, #1
   101c4:	e3a02002 	mov	r2, #2
   101c8:	e3a03003 	mov	r3, #3
   101cc:	e3a04004 	mov	r4, #4
   101d0:	e3a05005 	mov	r5, #5
   101d4:	e58d0028 	str	r0, [sp, #40]	@ 0x28
   101d8:	e58d102c 	str	r1, [sp, #44]	@ 0x2c
   101dc:	e58d2030 	str	r2, [sp, #48]	@ 0x30
   101e0:	e58d3034 	str	r3, [sp, #52]	@ 0x34
   101e4:	e58d4038 	str	r4, [sp, #56]	@ 0x38
   101e8:	e58d503c 	str	r5, [sp, #60]	@ 0x3c
   101ec:	e59d0028 	ldr	r0, [sp, #40]	@ 0x28
   101f0:	e59d102c 	ldr	r1, [sp, #44]	@ 0x2c
   101f4:	e59d2030 	ldr	r2, [sp, #48]	@ 0x30
   101f8:	e59d3034 	ldr	r3, [sp, #52]	@ 0x34
   101fc:	e59d4038 	ldr	r4, [sp, #56]	@ 0x38
   10200:	e59d503c 	ldr	r5, [sp, #60]	@ 0x3c
+  10204:	eb000021 	bl	0x10290
   10208:	e3a00000 	mov	r0, #0
   1020c:	e1a00000 	nop			@ (mov r0, r0)
   10210:	e3008044 	movw	r8, #68	@ 0x44
   10214:	e3408000 	movt	r8, #0
   10218:	e08dd008 	add	sp, sp, r8
   1021c:	e51de004 	ldr	lr, [sp, #-4]
   10220:	e12fff3e 	blx	lr

Disassembly of section .plt:

00010270 <.plt>:
   10270:	e52de004 	push	{lr}		@ (str lr, [sp, #-4]!)
   10274:	e300a2a4 	movw	sl, #676	@ 0x2a4
   10278:	e340a001 	movt	sl, #1
   1027c:	e1a0e00a 	mov	lr, sl
   10280:	e59ef000 	ldr	pc, [lr]
   10284:	e300c2a8 	movw	ip, #680	@ 0x2a8
   10288:	e340c001 	movt	ip, #1
   1028c:	e59cf000 	ldr	pc, [ip]
+  10290:	e300c2ac 	movw	ip, #684	@ 0x2ac
   10294:	e340c001 	movt	ip, #1
   10298:	e59cf000 	ldr	pc, [ip]

0x10290 is the starting address of printf@plt. However, in the text section, there are three places using bl instruction to call printf(), and each of these places has several str and ldr instructions to manipulate the stack beforehand.

[jserv]

Consider the minimal change below:

--- a/src/main.c
+++ b/src/main.c
@@ -85,7 +85,7 @@ int main(int argc, char *argv[])
     global_init();

     /* include libc */
-    if (libc)
+    if (libc && !dynlink)
         libc_generate();

     /* load and parse source code into IR */

It disables the built-in libc when --dynlink is enabled, since dynamic linking should use the system libc.

[jserv]

Notice that the second and third printf() calls have more than four arguments, certain arguments will be pushed to the stack due to the Arm calling convention.

OP_assign just does a register-to-register move (__mov_r(__AL, rd, rn)). The key issue seems to be in how the register mapping works. The problem is with ARM calling convention when passing more than 4 arguments to variadic functions like printf(). In ARM AAPCS (Arm Architecture Procedure Call Standard):

• First 4 arguments (r0-r3) are passed in registers
• Arguments beyond 4 must be pushed to the stack
• The stack must be properly aligned and arguments placed correctly

This suggests that parameter passing is handled differently. Currently, the virtual registers (0-7) are mapped to ARM physical registers (r0-r7). Looking at the code, rd = ph2_ir->dest directly uses the virtual register number as the ARM register number. This means:

• Virtual register 0 → ARM r0
• Virtual register 1 → ARM r1
• Virtual register 2 → ARM r2
• Virtual register 3 → ARM r3
• Virtual registers 4-7 → ARM r4-r7

In ARM calling convention, arguments beyond r3 should go to the stack, not to r4-r7. This is definitely a bug. When ir->dest = args++ assigns argument 4 to virtual register 4 (r4), argument 5 to virtual register 5 (r5), etc., but ARM calling convention requires arguments 5+ to be placed on the stack, not in r4-r7.

[jserv]

The original code had a bug where function calls with more than 4 arguments violated the AAPCS:

• Arguments 0-3 should go in registers r0-r3
• Arguments 4+ should be placed on the stack

However, shecc was incorrectly placing all arguments (0-7) in registers r0-r7, causing stack-based arguments to be passed incorrectly.

Consider the changes below:

diff --git a/src/reg-alloc.c b/src/reg-alloc.c
index c66a061..51cd2ea 100644
--- a/src/reg-alloc.c
+++ b/src/reg-alloc.c
@@ -520,12 +520,42 @@ void reg_alloc(void)
                         is_pushing_args = 1;
                     }
 
-                    src0 = prepare_operand(bb, insn->rs1, -1);
-                    ir = bb_add_ph2_ir(bb, OP_assign);
-                    ir->src0 = src0;
-                    ir->dest = args++;
-                    REGS[ir->dest].var = insn->rs1;
-                    REGS[ir->dest].polluted = 0;
+                    /* Check if next call is to external function (for ARM
+                     * calling convention)
+                     */
+                    insn_t *next_insn = insn->next;
+                    func_t *target_func = NULL;
+                    bool is_external_call = false;
+
+                    /* Look ahead for the OP_call to determine if it's external
+                     */
+                    while (next_insn && next_insn->opcode == OP_push)
+                        next_insn = next_insn->next;
+                    if (next_insn && next_insn->opcode == OP_call) {
+                        target_func = find_func(next_insn->str);
+                        is_external_call = target_func && !target_func->bbs;
+                    }
+
+                    /* ARM calling convention for external functions: first 4
+                     * args in r0-r3, rest on stack
+                     */
+                    if (is_external_call && args >= 4) {
+                        /* Arguments 4+: keep on stack, don't load into
+                         * registers. The variable is already on stack from
+                         * earlier spill_alive().
+                         */
+                    } else {
+                        /* Normal behavior for internal functions or first 4
+                         * args
+                         */
+                        src0 = prepare_operand(bb, insn->rs1, -1);
+                        ir = bb_add_ph2_ir(bb, OP_assign);
+                        ir->src0 = src0;
+                        ir->dest = args;
+                        REGS[ir->dest].var = insn->rs1;
+                        REGS[ir->dest].polluted = 0;
+                    }
+                    args++;
                     break;
                 case OP_call:
                     callee_func = find_func(insn->str);
@@ -535,8 +565,8 @@ void reg_alloc(void)
                     ir = bb_add_ph2_ir(bb, OP_call);
                     strcpy(ir->func_name, insn->str);
                     if (dynlink) {
-                        func_t *target_func = find_func(ir->func_name);
-                        target_func->is_used = true;
+                        func_t *target_fn = find_func(ir->func_name);
+                        target_fn->is_used = true;
                     }
 
                     is_pushing_args = 0;

Before the fix: All arguments were always loaded into sequential registers (r0, r1, r2, r3, r4, r5, r6, r7).
After the fix:

• Arguments 0-3: Still loaded into registers r0-r3 (normal behavior)
• Arguments 4+ for external calls: Skip register assignment entirely, keeping them on the stack where spill_alive() already placed them

Before Fix (Incorrect)
For a call like printf("Format %d %d %d %d %d", 1, 2, 3, 4, 5):

  load %x0, stack  # arg 0 → r0 ✓
  load %x1, stack  # arg 1 → r1 ✓
  load %x2, stack  # arg 2 → r2 ✓
  load %x3, stack  # arg 3 → r3 ✓
  load %x4, stack  # arg 4 → r4 ❌ (violates ARM calling convention)
  load %x5, stack  # arg 5 → r5 ❌ (violates ARM calling convention)
  call @printf

After Fix (Correct)
For the same call:

  load %x0, stack  # arg 0 → r0 ✓
  load %x1, stack  # arg 1 → r1 ✓
  load %x2, stack  # arg 2 → r2 ✓
  load %x3, stack  # arg 3 → r3 ✓
                   # args 4,5 stay on stack ✓ (ARM compliant)
  call @printf

[jserv]

I would like to ask @lecopzer for reviewing.

[DrXiao]

I tried to fix the Arm calling convention issue, but I found that the main problem seems not be register allocation. The actual problem is stack manipulation.

Consider a code like printf("%x %x %x %x %x\n", 1, 2, 3, 4, 5), if using arm-linux-gnueabi-gcc to compile, it produces the following machine code:

   1042c:	e3a03005 	mov	r3, #5
+  10430:	e58d3004 	str	r3, [sp, #4]
   10434:	e3a03004 	mov	r3, #4
+  10438:	e58d3000 	str	r3, [sp]
   1043c:	e3a03003 	mov	r3, #3
   10440:	e3a02002 	mov	r2, #2
   10444:	e3a01001 	mov	r1, #1
   10448:	e59f0010 	ldr	r0, [pc, #16]	@ 10460 <main+0x40>
   1044c:	ebffffac 	bl	10304 <printf@plt>

We can notice that only 4 and 5 are pushed to stack. The first four arguments are stored in r0-r3.

However, if using shecc to compile, it produces as follows:

   10148:	e30001b4 	movw	r0, #436	@ 0x1b4
   1014c:	e3400001 	movt	r0, #1
   10150:	e3a01001 	mov	r1, #1
   10154:	e3a02002 	mov	r2, #2
   10158:	e3a03003 	mov	r3, #3
   1015c:	e3a04004 	mov	r4, #4
   10160:	e3a05005 	mov	r5, #5
+  10164:	e58d0004 	str	r0, [sp, #4]
+  10168:	e58d1008 	str	r1, [sp, #8]
+  1016c:	e58d200c 	str	r2, [sp, #12]
+  10170:	e58d3010 	str	r3, [sp, #16]
+  10174:	e58d4014 	str	r4, [sp, #20]
+  10178:	e58d5018 	str	r5, [sp, #24]
   1017c:	e59d0004 	ldr	r0, [sp, #4]
   10180:	e59d1008 	ldr	r1, [sp, #8]
   10184:	e59d200c 	ldr	r2, [sp, #12]
   10188:	e59d3010 	ldr	r3, [sp, #16]
   1018c:	e59d4014 	ldr	r4, [sp, #20]
   10190:	e59d5018 	ldr	r5, [sp, #24]
   10194:	eb00001b 	bl	0x10208

The machine code uses r0-r5 to store the arguments, pushes all of them onto stack and load the values back from stack. This causes glibc's printf to receives incorrect values for the fourth and fifth arguments.

I think shecc generates machine code that pushes all arguments onto stack because spill_alive() may eventually call spill_var() to generate the OP_global_store / OP_store opcodes in the phase 2 IR.

shecc/src/reg-alloc.c

Lines 581 to 584 in 6a97bd7

	if (!is_pushing_args) {
	spill_alive(bb, insn);
	is_pushing_args = 1;
	}

I'm not sure why shecc behaves as described above, but I will try to review and fix it for AAPCS compliance.

[DrXiao]

I have rebased onto the master branch and updated the commits, so that we can review the updated implementation.

With the changes below, I can proceed with stage 1 compilation via make DYNLINK=1:

I have also temporarily created a new commit to apply part of the changes, and I will review everything to resolve any potential issues.

[DrXiao]

Since __libc_start_main calls the main wrapper in dynamic linking mode, the latter must preserve the contents of registers r4-r11 for the former accronding to the AAPCS. Therefore, the necessary instructions have been added to the code generator.

Additionally, the required documentation has been added.

[jserv]

Problems:

• Magic numbers 2 and 7 lack comments or constant definitions
• Calculation logic scattered across multiple locations, prone to inconsistency

[jserv]

Mention accurate PLT call offset calculation (12 bytes = 3 instructions) in comments.

[jserv]

Why save r12?

• r12 (IP) is a scratch register in AAPCS, external functions can freely modify it
• shecc uses r12 to store the global stack pointer
• Therefore, every external call must save/restore it

Consolidate comments.

[jserv]

The docs/dynamic-linking.md states:

• First four arguments are put into r0 - r3
• Other additional arguments are passed to stack
• Align the stack pointer to 8 bytes

However from the implementation, internal functions still use r0-r7 for parameters, only external functions follow AAPCS. This is a compiler optimization, but has risks. Consider the code below:

// Internal function
void internal_func(int a, int b, int c, int d, int e) {
    // shecc will read e from r4
}

// If this function is later changed to be exported via dynamic linking...
// External callers will put e on stack, internal code reads from r4 → Error!

Actions:

1. In dynamic linking mode, all functions should follow AAPCS (including internal ones)
2. Or explicitly check and error when exporting functions

[jserv]

Add interaction diagram with glibc dynamic linker.
Supplement explanation of lazy binding vs. immediate binding.

[DrXiao]

Do you have any recommended tools for creating the required diagram?

[jserv]

Do you have any recommended tools for creating the required diagram?

See:

• https://asciiflow.com/
• https://asciidiagrams.github.io/

[cubic-dev-ai]

4 issues found across 34 files

Prompt for AI agents (all 4 issues)

Understand the root cause of the following 4 issues and fix them.


<file name="docs/dynamic-linking.md">

<violation number="1" location="docs/dynamic-linking.md:106">
The PLT example uses `#:upeer16`, but the ARM assembler directive is `#:upper16`; the current typo makes the documented instruction invalid.</violation>
</file>

<file name="src/arm.c">

<violation number="1" location="src/arm.c:367">
The POP helper fails to increment SP because the encoded instruction clears the write-back bit; set W=1 so popping updates the stack pointer.</violation>
</file>

<file name="Makefile">

<violation number="1" location="Makefile:117">
make check-snapshot now fails unless DYNLINK is set because $(DYNLINK) expands to empty and the script expects a second argument. Please default this call to static mode when DYNLINK is unset.</violation>

<violation number="2" location="Makefile:128">
make update-snapshot now aborts unless DYNLINK is defined because the helper script insists on two arguments. Please provide a default value (e.g., static mode) when DYNLINK is unset.</violation>
</file>

_{React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.}

[cubic-dev-ai]

The PLT example uses #:upeer16, but the ARM assembler directive is #:upper16; the current typo makes the documented instruction invalid.

Prompt for AI agents

Address the following comment on docs/dynamic-linking.md at line 106:

<comment>The PLT example uses `#:upeer16`, but the ARM assembler directive is `#:upper16`; the current typo makes the documented instruction invalid.</comment>

<file context>
@@ -0,0 +1,128 @@
+```
+push	{lr}		@ (str lr, [sp, #-4]!)
+movw	sl, #:lower16:(&amp;GOT[2])
+movt	sl, #:upeer16:(&amp;GOT[2])
+mov	lr, sl
+ldr	pc, [lr]
</file context>

Suggested change

	movt sl, #:upeer16:(&GOT[2])
	movt sl, #:upper16:(&GOT[2])

[cubic-dev-ai]

The POP helper fails to increment SP because the encoded instruction clears the write-back bit; set W=1 so popping updates the stack pointer.

Prompt for AI agents

Address the following comment on src/arm.c at line 367:

<comment>The POP helper fails to increment SP because the encoded instruction clears the write-back bit; set W=1 so popping updates the stack pointer.</comment>

<file context>
@@ -357,6 +357,16 @@ int __ldm(arm_cond_t cond, int w, arm_reg rn, int reg_list)
+
+int __pop_word(arm_cond_t cond, arm_reg rt)
+{
+    return arm_encode(cond, (0x4 &lt;&lt; 4) | 0x9, 0xd, rt, 0x4);
+}
+
</file context>

Suggested change

	return arm_encode(cond, (0x4 << 4) | 0x9, 0xd, rt, 0x4);
	return arm_encode(cond, (0x4 << 4) | 0xB, 0xd, rt, 0x4);

[cubic-dev-ai]

make update-snapshot now aborts unless DYNLINK is defined because the helper script insists on two arguments. Please provide a default value (e.g., static mode) when DYNLINK is unset.

Prompt for AI agents

Address the following comment on Makefile at line 128:

<comment>make update-snapshot now aborts unless DYNLINK is defined because the helper script insists on two arguments. Please provide a default value (e.g., static mode) when DYNLINK is unset.</comment>

<file context>
@@ -72,44 +86,46 @@ config:
-	$(VECHO) &quot;Updating snapshot for %s\n&quot; $(ARCH)
-	tests/update-snapshots.sh $(ARCH)
+	$(VECHO) &quot;Updating snapshot for %s (DYNLINK=%s)\n&quot; $(ARCH) $(DYNLINK)
+	tests/update-snapshots.sh $(ARCH) $(DYNLINK)
 	$(VECHO) &quot;  OK\n&quot;
 
</file context>

Suggested change

	tests/update-snapshots.sh $(ARCH) $(DYNLINK)
	tests/update-snapshots.sh $(ARCH) $(if $(DYNLINK),$(DYNLINK),0)

[cubic-dev-ai]

make check-snapshot now fails unless DYNLINK is set because $(DYNLINK) expands to empty and the script expects a second argument. Please default this call to static mode when DYNLINK is unset.

Prompt for AI agents

Address the following comment on Makefile at line 117:

<comment>make check-snapshot now fails unless DYNLINK is set because $(DYNLINK) expands to empty and the script expects a second argument. Please default this call to static mode when DYNLINK is unset.</comment>

<file context>
@@ -72,44 +86,46 @@ config:
-	$(VECHO) &quot;Checking snapshot for %s\n&quot; $(ARCH)
-	tests/check-snapshots.sh $(ARCH)
+	$(VECHO) &quot;Checking snapshot for %s (%s mode)\n&quot; $(ARCH) $(DYNLINK)
+	tests/check-snapshots.sh $(ARCH) $(DYNLINK)
 	$(VECHO) &quot;  OK\n&quot;
 
</file context>

Suggested change

	tests/check-snapshots.sh $(ARCH) $(DYNLINK)
	tests/check-snapshots.sh $(ARCH) $(if $(DYNLINK),$(DYNLINK),0)

[cubic-dev-ai]

6 issues found across 34 files

Prompt for AI agents (all 6 issues)

Understand the root cause of the following 6 issues and fix them.


<file name="lib/c.h">

<violation number="1" location="lib/c.h:18">
Define INT_MIN as a signed negative constant; 0x80000000 has unsigned type, so using it for INT_MIN causes incorrect comparisons after integer promotions.</violation>
</file>

<file name="docs/static-linking.md">

<violation number="1" location="docs/static-linking.md:43">
The epilogue description reverses the stack restoration direction; the generated ARM return code adds total_size back into sp before popping lr, so documenting a subtraction misleads readers about how frames unwind.</violation>
</file>

<file name="docs/dynamic-linking.md">

<violation number="1" location="docs/dynamic-linking.md:106">
The PLT example misspells the ARM relocation modifier: it should use `#:upper16`, otherwise the listed instruction will not assemble successfully.</violation>
</file>

<file name="mk/arm.mk">

<violation number="1" location="mk/arm.mk:46">
The `ifndef LD_LINUX_PATH` check never fires because the variable was already defined (possibly as an empty string) by the earlier `:= $(shell ...)` assignment. Use an emptiness check so we fail fast when the sysroot lookup fails.</violation>
</file>

<file name="Makefile">

<violation number="1" location="Makefile:117">
`make check-snapshot` no longer works out of the box because the DYNLINK argument is omitted when the variable is unset, causing the helper script to exit with an error.</violation>

<violation number="2" location="Makefile:128">
`make update-snapshot` now fails because the DYNLINK parameter is missing when the variable is not explicitly set, triggering the helper script’s usage error.</violation>
</file>

_{React with 👍 or 👎 to teach cubic. Mention @cubic-dev-ai to give feedback, ask questions, or re-run the review.}

[cubic-dev-ai]

Define INT_MIN as a signed negative constant; 0x80000000 has unsigned type, so using it for INT_MIN causes incorrect comparisons after integer promotions.

Prompt for AI agents

Address the following comment on lib/c.h at line 18:

<comment>Define INT_MIN as a signed negative constant; 0x80000000 has unsigned type, so using it for INT_MIN causes incorrect comparisons after integer promotions.</comment>

<file context>
@@ -0,0 +1,85 @@
+#define false 0
+
+#define INT_MAX 0x7fffffff
+#define INT_MIN 0x80000000
+
+#if defined(__arm__)
</file context>

Suggested change

	#define INT_MIN 0x80000000
	#define INT_MIN (-2147483647 - 1)

[cubic-dev-ai]

The epilogue description reverses the stack restoration direction; the generated ARM return code adds total_size back into sp before popping lr, so documenting a subtraction misleads readers about how frames unwind.

Prompt for AI agents

Address the following comment on docs/static-linking.md at line 43:

<comment>The epilogue description reverses the stack restoration direction; the generated ARM return code adds total_size back into sp before popping lr, so documenting a subtraction misleads readers about how frames unwind.</comment>

<file context>
@@ -0,0 +1,66 @@
+  * For Arm32, the total size will be aligned to 8 bytes by the code generator.
+  * The size of the unused space is 20 bytes and is only used in dynamic linking mode.
+
+When a function completes execution, it restores the caller&#39;s stack pointer by subtracting `total_size` from `sp`, retrieves the return address from `[sp - 4]` and transfers control back to the caller.
+
+## About function arguments handling
</file context>

[cubic-dev-ai]

The PLT example misspells the ARM relocation modifier: it should use #:upper16, otherwise the listed instruction will not assemble successfully.

Prompt for AI agents

Address the following comment on docs/dynamic-linking.md at line 106:

<comment>The PLT example misspells the ARM relocation modifier: it should use `#:upper16`, otherwise the listed instruction will not assemble successfully.</comment>

<file context>
@@ -0,0 +1,128 @@
+```
+push	{lr}		@ (str lr, [sp, #-4]!)
+movw	sl, #:lower16:(&amp;GOT[2])
+movt	sl, #:upeer16:(&amp;GOT[2])
+mov	lr, sl
+ldr	pc, [lr]
</file context>

Suggested change

	movt sl, #:upeer16:(&GOT[2])
	movt sl, #:upper16:(&GOT[2])

[cubic-dev-ai]

The ifndef LD_LINUX_PATH check never fires because the variable was already defined (possibly as an empty string) by the earlier := $(shell ...) assignment. Use an emptiness check so we fail fast when the sysroot lookup fails.

Prompt for AI agents

Address the following comment on mk/arm.mk at line 46:

<comment>The `ifndef LD_LINUX_PATH` check never fires because the variable was already defined (possibly as an empty string) by the earlier `:= $(shell ...)` assignment. Use an emptiness check so we fail fast when the sysroot lookup fails.</comment>

<file context>
@@ -5,5 +5,54 @@ ARCH_DEFS = \
+            LD_LINUX_PATH := $(shell cd $(LD_LINUX_PATH) 2&gt;/dev/null &amp;&amp; pwd)
+            LD_LINUX_PATH := $(LD_LINUX_PATH)/$(shell echo $(CROSS_COMPILE) | sed s&#39;/.$$//&#39;)/libc
+            LD_LINUX_PATH := $(shell cd $(LD_LINUX_PATH) 2&gt;/dev/null &amp;&amp; pwd)
+            ifndef LD_LINUX_PATH
+                LD_LINUX_PATH = /usr/$(shell echo $(CROSS_COMPILE) | sed s&#39;/.$$//&#39;)
+                LD_LINUX_PATH := $(shell cd $(LD_LINUX_PATH) 2&gt;/dev/null &amp;&amp; pwd)
</file context>

[cubic-dev-ai]

make update-snapshot now fails because the DYNLINK parameter is missing when the variable is not explicitly set, triggering the helper script’s usage error.

Prompt for AI agents

Address the following comment on Makefile at line 128:

<comment>`make update-snapshot` now fails because the DYNLINK parameter is missing when the variable is not explicitly set, triggering the helper script’s usage error.</comment>

<file context>
@@ -72,44 +86,46 @@ config:
-	$(VECHO) &quot;Updating snapshot for %s\n&quot; $(ARCH)
-	tests/update-snapshots.sh $(ARCH)
+	$(VECHO) &quot;Updating snapshot for %s (DYNLINK=%s)\n&quot; $(ARCH) $(DYNLINK)
+	tests/update-snapshots.sh $(ARCH) $(DYNLINK)
 	$(VECHO) &quot;  OK\n&quot;
 
</file context>

Suggested change

	tests/update-snapshots.sh $(ARCH) $(DYNLINK)
	tests/update-snapshots.sh $(ARCH) $(if $(strip $(DYNLINK)),$(DYNLINK),0)

[cubic-dev-ai]

make check-snapshot no longer works out of the box because the DYNLINK argument is omitted when the variable is unset, causing the helper script to exit with an error.

Prompt for AI agents

Address the following comment on Makefile at line 117:

<comment>`make check-snapshot` no longer works out of the box because the DYNLINK argument is omitted when the variable is unset, causing the helper script to exit with an error.</comment>

<file context>
@@ -72,44 +86,46 @@ config:
-	$(VECHO) &quot;Checking snapshot for %s\n&quot; $(ARCH)
-	tests/check-snapshots.sh $(ARCH)
+	$(VECHO) &quot;Checking snapshot for %s (%s mode)\n&quot; $(ARCH) $(DYNLINK)
+	tests/check-snapshots.sh $(ARCH) $(DYNLINK)
 	$(VECHO) &quot;  OK\n&quot;
 
</file context>

Suggested change

	tests/check-snapshots.sh $(ARCH) $(DYNLINK)
	tests/check-snapshots.sh $(ARCH) $(if $(strip $(DYNLINK)),$(DYNLINK),0)

[jserv]

The documentation should address PLT performance overhead. First function call path:

1. Call PLT stub
2. PLT stub reads GOT entry
3. GOT entry points to resolver
4. Resolver resolves symbol and updates GOT
5. Jump to actual function

Subsequent calls: Only steps 1-2-5

Thus, the overhead is 5-10 CPU cycles (compared to direct call). For a bootstrapping compiler, this overhead is acceptable.

[jserv]

Add/clarify comments:

• PLT stub executes and immediately jumps (lw __pc, [__r12])
• Target function will restore correct r12 from [sp+16]
• r12 modification is not persistent

[jserv]

ARM EABI specifies r10 might be the stack limit register, but on Linux ARM EABI, r10 is callee-saved, and the dynamic linker will protect it, so there is no problem.

Code is correct, but lacks comments explaining register choices.

[jserv]

Why is GOT[N] = 0 needed as an end marker?

Dynamic linker determines GOT size via DT_PLTGOT and DT_PLTRELSZ, does not need a terminator.

[DrXiao]

I compiled a simple program with GCC and referred to its GOT generation, but I misunderstood that a terminator was necessary. I will fix it.

[jserv]

ARM EABI requires stack to be aligned to 8 bytes at public interface boundaries (i.e., when calling functions). Internal stack frames can be unaligned, but must be aligned when calling external functions.

More comments.

[jserv]

The behavior of the current implementation:

• GOT is located in writable segment (.data segment)
• Doesn't implement PT_GNU_RELRO program header
• Doesn't set DT_BIND_NOW (force immediate binding)

It means:

1. GOT can be modified at runtime → ROP attack vector
2. No FULL RELRO → Function pointers might be hijacked

For the current stage, this is acceptable. Document the limitations.

[jserv]

Consider to place abi.sh as an additional test suite for ABI compliance.

[DrXiao]

The docs/dynamic-linking.md states:

• First four arguments are put into r0 - r3
• Other additional arguments are passed to stack
• Align the stack pointer to 8 bytes

However from the implementation, internal functions still use r0-r7 for parameters, only external functions follow AAPCS. This is a compiler optimization, but has risks. Consider the code below:

// Internal function
void internal_func(int a, int b, int c, int d, int e) {
    // shecc will read e from r4
}

// If this function is later changed to be exported via dynamic linking...
// External callers will put e on stack, internal code reads from r4 → Error!

Actions:

1. In dynamic linking mode, all functions should follow AAPCS (including internal ones)
2. Or explicitly check and error when exporting functions

• External functions: C standard functions (e.g.: printf, strcpy) provided by glibc.
• Internal functions: Functions compiled by shecc.

I will try to improve shecc to make all internal and external functions follow AAPCS. However, If we consider that external functions may call internal functions, I think there is another issue related to accessing global variables.

Since internal functions rely on r12 to access global variables on the global stack, such accesses may become incorrect because r12 could be modified by external functions.

Therefore, how about the following conceptual approach:

• Add a global object (4 bytes) to .data section.
• After the global stack is prepared and r12 is set, the main wrapper also stores the global stack pointer in this global object.
• When an internal function is called, it first retrieves the global stack pointer from the global object, loads it into r12, and then continues execution.

Since the starting address of .data (elf_data_start) is determined at compile time, accessing the aforementioned global object is straightforward.