update @export to handle linksection

[andrewrk]

Use case: putting .gdb_script entries in generic types. See also #25.

Here's code that I tried:

fn Generic(comptime T: type) type {
    return struct {
        const python_code = @typeName(@This()) ++
            \\ your generic python
            \\ code goes here
        ;
        extern const script linksection(".debug_gdb_scripts") = "\x04gdb.inlined-script\n" ++ python_code ++ [1]u8{0};
        comptime {
            if (builtin.mode == .Debug) {
                @export("gdb_script" ++ @typeName(@This()), script, .Strong);
            }
        }
    };
}

comptime {
    _ = Generic(i32);
    //_ = Generic(f64);
}

I needed to make a small improvement to @export to support arrays:

--- a/src/ir.cpp
+++ b/src/ir.cpp
@@ -13901,6 +13901,15 @@ static IrInstruction *ir_analyze_instruction_export(IrAnalyze *ira, IrInstructio
                 want_var_export = true;
             }
             break;
+        case ZigTypeIdArray:
+            if (!type_allowed_in_extern(ira->codegen, target->value.type->data.array.child_type)) {
+                ir_add_error(ira, target,
+                    buf_sprintf("array element type '%s' not extern-compatible",
+                        buf_ptr(&target->value.type->data.array.child_type->name)));
+            } else {
+                want_var_export = true;
+            }
+            break;
         case ZigTypeIdMetaType: {
             ZigType *type_value = target->value.data.x_type;
             switch (type_value->id) {
@@ -13968,7 +13977,6 @@ static IrInstruction *ir_analyze_instruction_export(IrAnalyze *ira, IrInstructio
         case ZigTypeIdInt:
         case ZigTypeIdFloat:
         case ZigTypeIdPointer:
-        case ZigTypeIdArray:
         case ZigTypeIdComptimeFloat:
         case ZigTypeIdComptimeInt:
         case ZigTypeIdUndefined:

And then the above example gives me:

/home/andy/downloads/zig/build/test.zig:7:41: error: cannot set section of external variable 'script'
        extern const script linksection(".debug_gdb_scripts") = "\x04gdb.inlined-script\n" ++ python_code ++ [1]u8{0};
                                        ^

This compile error makes sense and should stay. The link section should be a parameter to @export. But we do want the concept of default link sections. We also want strong linkage to be the default. I propose that the definition of @export is changed to this:

fn @export(target: var, comptime options: ExportOptions) void

Where ExportOptions is defined in @import("builtin") like this:

const ExportOptions = struct {
    name: []const u8,
    linkage: GlobalLinkage = .Strong,
    section: ?[]const u8 = null,
};

[andrewrk]

Oh, actually this compile error should go away:

External declarations may have an explicit section specified. Section information is retained in LLVM IR for targets that make use of this information. Attaching section information to an external declaration is an assertion that its definition is located in the specified section. If the definition is located in a different section, the behavior is undefined.

I'm still in favor of this proposal (maybe we make an error for if the sections disagree) but in the meantime the compile error for section names on extern variables can go away.

[andrewrk]

I fixed the issue with @export not respecting the name. So this example now works (See the LLVM IR output below):

// This is to remove the SHF_ALLOC flag from the .gdb_debug_scripts section so that it does not get garbage collected by the linker.
comptime {
    asm (
        \\.pushsection ".debug_gdb_scripts", "MS",@progbits,1
        \\.popsection
    );
}

fn Generic(comptime T: type) type {
    return struct {
        const python_code = @typeName(@This()) ++
            \\ your generic python
            \\ code goes here
        ;
        // note that you have to make this an extern for now
        extern const script linksection(".debug_gdb_scripts") = "\x04gdb.inlined-script\n" ++ python_code ++ [1]u8{0};
        comptime {
            if (builtin.mode == .Debug) {
                @export("gdb_script" ++ @typeName(@This()), script, .Strong);
            }
        }
    };
}

comptime {
    _ = Generic(i32);
    _ = Generic(f64);
}

Relevant LLVM output:

@"gdb_scriptGeneric(i32)" = dso_local unnamed_addr constant [69 x i8] c"\04gdb.inlined-script\0AGeneric(i32) your generic python\0A code goes here\00", section ".debug_gdb_scripts", align 1
@"gdb_scriptGeneric(f64)" = dso_local unnamed_addr constant [69 x i8] c"\04gdb.inlined-script\0AGeneric(f64) your generic python\0A code goes here\00", section ".debug_gdb_scripts", align 1

This will unblock #2681, which should not wait on this issue to be solved, because it will remain open until @export has the new function signature.