users June 2021

users@lists.genode.org

9 participants
6 discussions

Error: LD: symbol not found: '__data_start'
by Alexander Tormasov 21 Jun '21

21 Jun '21

when running test application I encounter a new problem of dynamic linker [init -> test-go] 0x1000000 .. 0x10ffffff: linker area [init -> test-go] Error: LD: symbol not found: '__data_start' [init -> test-go] Error: Uncaught exception of type 'Linker::Not_found' any ideas how to fix? seems that main binary test-go do have a weak ref to this symbol as nm show: w __data_start in some places of new code appeared after 10.3 gcc I found extern const char __data_start[] __attribute__ ((weak)); where I can add it, in what ld script? Sincerely, Alexander

3 8

Found something
by Uwe 19 Jun '21

19 Jun '21

I have found a testable(!),small(!) TCB implementation of TLS. Would it be cool if genode had a verified(!), isolated(!) daemon, that does all things related to external communication, of course encrypted?

1 0

21.05 toolchain C tls variables compilation problem
by Alexander Tormasov 11 Jun '21

11 Jun '21

small c file: typedef int G; __thread G *g __asm__("" "runtime.g"); G* runtime_g(void) __attribute__ ((noinline, no_split_stack)); G* runtime_g(void) { return g; } during compilation using genode-x86-gcc 10.3 error in asm (and checked genode-x86-as as well): tt1.s: Assembler messages: tt1.s:22: Error: junk at end of line, first unrecognized character is `*' tt1.s:25: Error: unrecognized symbol type "" tt1.s:25: Error: junk at end of line, first unrecognized character is `*' tt1.s:26: Error: expected comma after name `__emutls_v.' in .size directive tt1.s:27: Error: invalid character '*' in mnemonic tt1.s:13: Error: invalid operands (*UND* and *UND* sections) for `*’ generated asm: .file "tt1.c" .text .globl runtime_g .type runtime_g, @function runtime_g: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $__emutls_v.*runtime.g, %edi call __emutls_get_address movq (%rax), %rax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size runtime_g, .-runtime_g .globl __emutls_v.*runtime.g ^^^^^^^ first error line ^^^^^^^^^^^^^^^^^ .data .align 32 .type __emutls_v.*runtime.g, @object .size __emutls_v.*runtime.g, 32 __emutls_v.*runtime.g: .quad 8 .quad 8 .quad 0 .quad 0 .ident "GCC: (GNU) 10.3.0"

3 7

depot/extract: make: execvp: bash: Argument list too long
by Roman Iten 09 Jun '21

09 Jun '21

Hello Genodians Our continuous integration pipeline is split into several stages which correspond with the Genode depot tools. The artifacts created by the depot tool are passed to the subsequent stages: - "Extract"-stage: extract all API/source archives. - "Build"-stage: build binary archives from the source archives extracted during the previous stage. For each architecture (arm_v7a, arm_v8a, x86_64, etc.) a dedicated build job is triggered. These jobs run in parallel and possibly on different hardware. - "Run"-stage: execute the run scripts. Everything is "imported from depot" so that nothing needs to be compiled during this stage. - "Publish"-stage: publish API/source/binary/package archives For the "Build"-stage, we introduced meta packages like "pkg/gapfruit_ci-x86_64", "pkg/gapfruit_ci-arm_v7a", etc. that include every archive we want to build for that architecture. These meta-packages are also used by the "Extract"-stage, so that for example `tool/depot/extract rite/pkg/gapfruit_ci-x86_64 rite/pkg/gapfruit_ci-arm_v7a` can be called. Now that the number of archives became too large and `depot/extract` complains: `make: execvp: bash: Argument list too long`. Apparently, the aggregated argument list passed to `make` contains every archive including all dependencies. Duplicates (packages and dependencies that are build for x86_64 as well as arm_v7a, etc.) are not removed. Is this currently a limitation of the `tool/depot/extract`? Before I try my luck to tackle it myself, I'd appreciate every hint how to do so. Or am I using `depot/extract` wrong? Do you see an alternative regarding the use case described above? Thanks Roman PS, I disabled the dependency check in `tool/depot/mk/dependencies.inc` completely. See the discussion [1,2] on the Genode mailing list. [1] https://lists.genode.org/pipermail/users/2018-May/006079.html [2] https://lists.genode.org/pipermail/users/2018-June/006085.html

4 5

Partitioning Fun Finale (Re: I am having some strange difficulty formatting a GPT partition within Sculpt)
by baconicsynergy＠protonmail.ch 04 Jun '21

04 Jun '21

It seems my plans for Genode to fit in my partition scheme can come to fruition after all :) Martin: > I created a quickfix on my branch > https://github.com/m-stein/genode/tree/sculpt-21.03b-baconicsynergy. > Could you give it a try? I hope this is the only place where the Sculpt > Manager assumes such a limit. Maybe we should come up with a more > generic solution to this problem. It worked! I was able to format the final partition for use with Genode. John: > In my experience, the ISO image works fine if you burn it to a CD-ROM or > use it as a virtual CD in a VM. But if you want to copy it to a USB > stick, you need to switch to creating a bootable disk image by changing > the line in "build.conf" from: > > QEMU_RUN_OPT := --include power_on/qemu --include log/qemu --include > image/iso > > to: > > QEMU_RUN_OPT := --include power_on/qemu --include log/qemu --include > image/disk That did the trick too. This is actually in the instructions in the link Christian gave me: > With pleasure I'd like to refer you to > https://genode.org/documentation/articles/sculpt-21-03#Building_the_boot_im… Thanks everyone! I'm going to experiment a little bit now and study as much Genode as I can baconicsynergy

2 1

filesystem testing
by Stefan Thöni 01 Jun '21

01 Jun '21

Hello Genodians, we have a requirement for additional filesystem tests especially to measure performance and check reliability in reset/crash scenarios. The tests should be modular to cover different file systems and block devices including CBE as well as different platforms to detect any regressions. Would such tests be generally welcome as an upstream contribution to the genode framework from us? If so, I would then create an issue in the genode project at github to discuss the best way to go about this. Bests Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users June 2021