~mcf

https://mforney.org

Trackers

~mcf/cproc

Last active 3 months ago

~mcf/dnssec-rr

Last active 4 months ago

~mcf/libtls-bearssl

Last active 9 months ago

~mcf/qbe

Last active 1 year, 5 months ago

~mcf/oasis

Last active 1 year, 5 months ago

~mcf/sbase

Last active 1 year, 7 months ago

~mcf/samurai

Last active 1 year, 10 months ago

#72 __attribute__((packed)) 3 months ago

Ticket created by ~mcf on ~mcf/cproc

#71 Prevent creation of value with no QBE representation (long double) 5 months ago

Ticket created by ~mcf on ~mcf/cproc

Right now, cproc can segfault if it tries to call a function with a long double argument. We currently detect a missing representation when we try to emit it, but we should actually just prevent construction of a value with no QBE representation in the first place.

Another manifestation of this bug is if you try to call a function returning long double, ignoring the result. This should be a compile error, but cproc compiles it as if it were void.

funcinst currently uses repr == NULL for function calls to indicate that it has no return value, so we can't tell if we are calling a function with no return value, or the return value has no representation.

To fix this, perhaps we could add a special funccall function to create call instructions. There is already some call-specific code in funcinst, so this is probably the right thing to do.

#70 cproc -Dfoo=bar syntax is not supported 5 months ago

on ~mcf/cproc

REPORTED RESOLVED INVALID

#70 cproc -Dfoo=bar syntax is not supported 5 months ago

Comment by ~mcf on ~mcf/cproc

I'm guessing you had some other flag that was not supported. I've run into this occasionally, too, since cproc didn't make it clear which option was problematic. C compilers are typically passed a lot of options, which makes it difficult to figure it out by inspecting the full command.

I pushed a commit that should help with this.

#70 cproc -Dfoo=bar syntax is not supported 5 months ago

Comment by ~mcf on ~mcf/cproc

I'm not sure what you mean by "getopt-style arguments". The cproc driver does indeed support both -Dfoo=bar and -D foo=bar, and passes them on to the preprocessor.

#1 Variable-length arrays 6 months ago

Comment by ~mcf on ~mcf/cproc

Yes, I think QBE should be able to save and restore the stack pointer.

Consider the following program:

#include <stddef.h>
size_t x;
void g(char *);
void f(void) {
	for (;;) {
		char a[x];
		g(a);
	}
}

clang turns this into this LLVM IR:

define dso_local void @f() local_unnamed_addr #0 {
  br label %1

1:                                                ; preds = %1, %0
  %2 = load i64, i64* @x, align 8, !tbaa !2
  %3 = call i8* @llvm.stacksave()
  %4 = alloca i8, i64 %2, align 16
  call void @g(i8* nonnull %4) #1
  call void @llvm.stackrestore(i8* %3)
  br label %1
}

which gets translated to this x86_64 asm:

f:                                      # @f
        pushq   %rbp
        movq    %rsp, %rbp
        pushq   %rbx
        pushq   %rax
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        movq    %rsp, %rbx
        movq    x(%rip), %rax
        movq    %rsp, %rdi
        addq    $15, %rax
        andq    $-16, %rax
        subq    %rax, %rdi
        movq    %rdi, %rsp
        callq   g
        movq    %rbx, %rsp
        jmp     .LBB0_1

Rather than allocating more and more stack space, the stack pointer is saved at the beginning of the loop body, and restored at the end.

#1 Variable-length arrays 6 months ago

Comment by ~mcf on ~mcf/cproc

I updated the description with what I concluded last time I investigated this.

Regarding your proposal, I think that has worst-case quadratic memory usage, which might not be acceptable. For example, something that should be safe, like

for (size_t i = 0; i < 8192; ++i) {
	char a[i];
	f(a, i);
}

would use 32 MiB on the stack. A possible variation could be to allocate in powers of 2, which should use use at most twice the required size.

I don't think the copy is necessary since VLAs can't be resized in C.

In any case, I don't it's worth trying to emulate full VLAs until QBE has the proper support. For now, supporting VLAs that don't appear under any labels or loop bodies is probably sufficient for most code.

#2 Full support for openssl cipher strings 9 months ago

Comment by ~mcf on ~mcf/libtls-bearssl

Done in 1f74e3e5ac.

REPORTED RESOLVED FIXED

#2 Full support for openssl cipher strings 9 months ago

Ticket created by ~mcf on ~mcf/libtls-bearssl

These are documented at https://man.openbsd.org/SSL_CTX_set_cipher_list.3. Right now, we support most of these, except for @STRENGTH and prefixed cipher strings.

#1 Issue tracker for https://git.sr.ht/~mcf/libtls-bearssl 9 months ago

Comment by ~mcf on ~mcf/libtls-bearssl

Whoops.

REPORTED RESOLVED INVALID