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.

Updated usage: (9/18 23:28 updated)

# Perform bootstrapping process for the dynamically linked shecc.
$ make LINK_MODE=dynamic

# 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.

[cubic-dev-ai]

8 issues found across 15 files

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

[cubic-dev-ai]

Add const to strcmp parameters for correctness and compatibility with libc.

Prompt for AI agents

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

<comment>Add const to strcmp parameters for correctness and compatibility with libc.</comment>

<file context>
@@ -0,0 +1,47 @@
+
+/* string-related functions */
+int strlen(char *str);
+int strcmp(char *s1, char *s2);
+int strncmp(char *s1, char *s2, int len);
+char *strcpy(char *dest, char *src);
</file context>

Suggested change

	int strcmp(char *s1, char *s2);
	int strcmp(const char *s1, const char *s2);

[cubic-dev-ai]

DYN_LINKER points to ARM’s /lib/ld-linux.so.3; set this to the correct RISC-V dynamic loader path to avoid invalid interpreter in produced executables.

Prompt for AI agents

Address the following comment on mk/riscv.mk at line 10:

<comment>DYN_LINKER points to ARM’s /lib/ld-linux.so.3; set this to the correct RISC-V dynamic loader path to avoid invalid interpreter in produced executables.</comment>

<file context>
@@ -7,4 +7,12 @@ ARCH_DEFS = \
     \#define ARCH_PREDEFINED \&quot;__riscv\&quot; /* Older versions of the GCC toolchain defined __riscv__ */\n$\
     \#define ELF_MACHINE 0xf3\n$\
     \#define ELF_FLAGS 0\n$\
+    \#define DYN_LINKER \&quot;/lib/ld-linux.so.3\&quot;\n$\
+    \#define LIBC_SO \&quot;libc.so.6\&quot;\n$\
+    \#define PLT_FIXUP_SIZE 20\n$\
</file context>

[cubic-dev-ai]

Potential null dereference of func; check func for NULL before accessing bbs to handle unresolved/external symbols safely.

Prompt for AI agents

Address the following comment on src/arm-codegen.c at line 299:

<comment>Potential null dereference of func; check func for NULL before accessing bbs to handle unresolved/external symbols safely.</comment>

<file context>
@@ -282,15 +296,23 @@ void emit_ph2_ir(ph2_ir_t *ph2_ir)
     case OP_call:
         func = find_func(ph2_ir-&gt;func_name);
-        emit(__bl(__AL, func-&gt;bbs-&gt;elf_offset - elf_code-&gt;size));
+        if (func-&gt;bbs)
+            ofs = func-&gt;bbs-&gt;elf_offset - elf_code-&gt;size;
+        else
</file context>

[cubic-dev-ai]

Combining --dynlink with --no-libc is not validated; the build may produce unusable output. Consider rejecting conflicting flags or reconciling libc inclusion with dynlink mode.

Prompt for AI agents

Address the following comment on src/main.c at line 61:

<comment>Combining --dynlink with --no-libc is not validated; the build may produce unusable output. Consider rejecting conflicting flags or reconciling libc inclusion with dynlink mode.</comment>

<file context>
@@ -58,6 +58,8 @@ int main(int argc, char *argv[])
             hard_mul_div = true;
         else if (!strcmp(argv[i], &quot;--no-libc&quot;))
             libc = false;
+        else if (!strcmp(argv[i], &quot;--dynlink&quot;))
+            dynlink = true;
         else if (!strcmp(argv[i], &quot;-o&quot;)) {
</file context>

[DrXiao]

Using /lib/ld-linux-armhf.so.3 is preferable, as the Raspberry Pi (and various Arm32 based environments) Linux image uses this armhf configuration.

Does it mean that shecc should be modified to use the hard-float ABI? I previously noticed that shecc uses the soft-float ABI because the current makefile fragment defines ELF_FLAGS as 0x5000200 (which means soft-float ABI).

shecc/mk/arm.mk

Line 8 in f265042

\#define ELF_FLAGS 0x5000200\n$\

[jserv]

Does it mean that shecc should be modified to use the hard-float ABI?

Yes, it is time to comply with armhf ABI.

[DrXiao]

Since the stage 1 compiler fails to compile the stage 2 compiler when running on an Arm machine, I will convert this pull request to draft until the issue is resolved.

When I execute the stage 1 compiler on my BeagleBone Black with strace, it shows the following output:

$ strace out/shecc-stage1.elf
execve("out/shecc-stage1.elf", ["out/shecc-stage1.elf"], 0xbeccd690 /* 22 vars */) = 0
brk(NULL)                               = 0x1b79000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} ---
+++ killed by SIGSEGV +++
Segmentation fault

edit:
If I invoke the stage 1 compiler using the ELF interpreter, it runs successfully and is able to generate the stage 2 compiler.

$ /lib/ld-linux-armhf.so.3 out/shecc-stage1.elf --dynlink -o shecc-stage2.elf src/main.c

[jserv]

Mention https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads as well.

[DrXiao]

I want to conclude the current progress here:

1. After introducing 23712d9 and 5e89621, the bootstrapping process and unit tests can complete on my BeagleBone Black running Debian Linux.

   As the previous comment stated, because the dynamically linked shecc encountered a Segmentation fault if running on an Arm machine, and then I modified the program headers with the following changes:

   • Set p_align to the page size because it is required by the ELF interpreter.
   • Make the ELF header and program headers be loaded to the first segment and set the virtual/physical address to ELF_START, thereby avoiding the segfault (SEGV_MAPERR). However, I currently cannot give a good illustration to explain why.

   Later, to also improve the load segments with proper permissions, I eventually refined the load segments so that the certain read-only sections (.text, plt ...) are located in the first segment, and other sections reside in the second segment.

2. I downloaded the ARM GNU toolchain from the ARM developer website and validated my changes, and it is unexpected that the bootstrapping process could still complete but the unit tests will fail for the cases using printf():

   e.g.:

   /* test.c */
   int main(void)
   {
       printf("Hello %08x\n", 1);
       return 0;
   }

   Then, I noticed that the program behaved differently when using different ELF interpreters:

   $ qemu-arm -L /home/drxiao/tools/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc out/shecc-stage2.elf --dynlink -o test test.c
   
   # Using the manually downloaed ELF interpreter causes a BUS error.
   $ qemu-arm -L /home/drxiao/tools/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-linux-gnueabihf/arm-none-linux-gnueabihf/libc test
   qemu: uncaught target signal 7 (Bus error) - core dumped
   Bus error (core dumped)
   
   # It can run successfully when using the ELF interpreter installed via apt-get.
   $ qemu-arm -L /usr/arm-linux-gnueabihf test
   Hello 00000001

3. In fact, I have tried some ways to reduce duplication between lib/c.c and lib/c.h. Since I encountered multiple segmentation faults during the refinement, this is still a work in progress.

[DrXiao]

2. I downloaded the ARM GNU toolchain from the ARM developer website and validated my changes, and it is unexpected that the bootstrapping process could still complete but the unit tests will fail for the cases using printf():

With commit 73a3d5d, the unit tests pass regardless of whether the toolchain is downloaded from the Arm developer website or installed via apt. (I used arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-linux-gnueabihf to validate and confirm this commit.)

The root cause is that external functions may access 8-byte data on the stack. If any internal function leaves the stack misaligned, such access can trigger a Bus error. Therefore, the new commit is to ensure that the stack is always aligned with 8 bytes after each stack manipulation.

Reference:

(This figure is taken from ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition. )

I also validated this on my BeagleBone Black, and both bootstrapping and unit tests still pass.

---

By the way, when testing shecc on BeagleBone Black, I have to create a swap space to ensure the bootstrapping can complete; otherwise, the bootstrapping will fail due to insufficient memory.

[DrXiao]

@jserv , as stated in the previous comment, I have tried several approaches to refine c.c and c.h, but I eventually found that the current parser may contain bugs when handling forward declarations, causing compiled programs to run unexpectedly.

Since it is quite difficult for me to address the root cause at the moment, I have created an issue to track. Could I postpone the refinement until the issue is resolved?

[jserv]

@jserv , as stated in the previous comment, I have tried several approaches to refine c.c and c.h, but I eventually found that the current parser may contain bugs when handling forward declarations, causing compiled programs to run unexpectedly.

@ChAoSUnItY, can you proceed with #305 ?

[ChAoSUnItY]

can you proceed with #305 ?

I'll take a look into it.