similar to: error on implementing printf

> It's the linkers job to hook together functions and definitions that end up in the same binary. Your OS will then hook in functions from other binaries when your executable is loaded into memory. How does it know whether it is a system function or a user-defined function? It seems that user functions have higher priorities over system functions as demonstrated by the following example.

Hi In the generated .ll file, it may have something like this. How does LLVM know where to look for the definition of printf? Is it documented somewhere? Thanks. declare i32 @printf(i8*, ...) #1 -- Regards, Peng

I got a qemu crash and errors reported in bochs while trying to get latest core32 branch working (pxelinux): qemu: fatal: Trying to execute code outside RAM or ROM at 0xe6e8aa07 EAX=6e0c7811 EBX=000034b3 ECX=ca68b338 EDX=00000048 ESI=750e3fff EDI=00000020 EBP=d07e4988 ESP=00102324 EIP=e6e8aa07 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0028 00000000 ffffffff 00cf9300 CS =0020

I have the following toolchain: $ ld --version GNU ld version 2.15.90.0.3 20040415 $ gcc --version gcc (GCC) 3.3.2 I attempted to build klibc with this toolchain. It builds without errors, but the included "ash" shell does not function properly. Testcase: read cmdline </proc/cmdline echo $cmdline The first command prints a message: cannot open /proc/cmdline: error 14 Other

On 2020-07-27 19:20, hpa at zytor.com wrote: > > I'm not so sure they have dealt with it in the sense of having it work on all architectures. *Most* of the problems are related to the shifting the arguments by one, which can cause a bunch of problems, especially if it means the arguments spill to memory. However, I have absolutely no idea how to correctly implement syscall(3) on s390

On Mon, 2020-07-27 at 05:46 -0700, hpa at zytor.com wrote: > On July 27, 2020 2:43:36 AM PDT, Christian Eggers <ceggers at arri.de> wrote: > > On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote: > > > On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote: > > > > ... > > > > libkeyutils usually invokes syscall() directly. As syscall()

In klibc-0.114, any shell script like this: ====================================================================== #!/path/to/klibc-0.114/ash/sh echo hi ====================================================================== ...elicits the following error when executed: /var/tmp/hack.sh: Can't open /var/tmp/hack.sh Running under strace, I get: execve("/var/tmp/hack.sh",

Hi, after a year, I decided to hack on klibc again. I?ve reworked both the patch to add mkstemp(), discussing to use AT_RANDOM as cheap entropy source on IRC (if there will ever be another entropy consumer, I can quickly write a minimal arc4random() seeded from it, as it has only 16 octets), capable of making a working mksh (static and shared) on amd64/xen, and the m68k support code, leading to

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

Hi all, Date: Thu, 10 Dec 2009 22:55:20 +0800 Subject: [PATCH] [RFC] lib: add a hex dump lib function I think it would be better to have a hex dump routine; it would make debugging much easier since it can dump the data, like fs meta data, in a hex style, just like what the 'hexdump -C file' command does. BTW, I'm not sure where should I to put the hexdump function declaration. For

This is a small set of patches for elflink branch based on feng's elflink branch. hpa, It seems that I can't log on terminus by ssh at home. So I can't push these patches on my git tree. Liu Aleaxander (4): elflink: Cleanup some warnings elflink: Fix the wrong malloc size in enter_cmdline elflink: Do clear screen even if we have no pDraw_Menu method elflink: Add Ctrl-p +

Hi, This is a another small set of fixes about CLI on elflink branch. Liu Aleaxander (3): elflink: use 'input' as the prompt of the CLI elflink: Add ctrl-R key bind support elflink: handle the NULL return of edit_cmdline core/elflink/cli.c | 88 +++++++++++++++++++++++++++++++++++++++++--- core/elflink/load_env32.c | 4 ++- 2 files changed, 85 insertions(+), 7

The current code only works iff the tsize option is set. This patch fixes the handling of the OACK packet and makes the code work with all combinations of the tsize and blksize options. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> diff --git a/core/pxe.c b/core/pxe.c index 81d3e23..a4b8a14 100644 --- a/core/pxe.c +++ b/core/pxe.c @@ -913,8 +913,10 @@ static void pxe_searchdir(char

the current code can just handle one option beacuse I put the do-while loop in the wrong position. Signed-off-by: Liu Aleaxander <Aleaxander at gmail.com> --- core/pxe.c | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/core/pxe.c b/core/pxe.c index 81d3e23..bda1a54 100644 --- a/core/pxe.c +++ b/core/pxe.c @@ -928,20 +928,20 @@ static void

Hi, 1. I'm making an R package in Windows 2000, and I'm including the .c files. Everything works fine, except that when I call the printf() function in the C code, it doesn't actually print anything. I'm including the following header files: #include <stdio.h> #include <math.h> #include <sys/types.h> #include <stdlib.h> and I have the recommended MinGW

Hello, My code: (CallInst *CI, IRBuilder<> &B) SmallVector<Value *, 8> args; Value *v = B.CreateGlobalString("hi", "str"); args.push_back(v); SmallVector<Type*, 8> params; params.push_back(v->getType()); Module *M = B.GetInsertBlock()->getParent()->getParent(); FunctionType *printfType =

On 5/17/2018 4:04 PM, Davide Italiano via llvm-dev wrote: > On Thu, May 17, 2018 at 3:53 PM, Dávid Bolvanský via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hello, >> >> I was thinking about a new possible simplification in InstCombine which >> would transform code like this: >> >> const char * NAME = "Prog"; >> >> void

I'm not sure what the root cause is, but printf writes to fd 0: mandarine:/usr/src/packages/BUILD/udev-015/klibc# ./utils/true blah mandarine:/usr/src/packages/BUILD/udev-015/klibc# ./utils/true >/dev/null blah mandarine:/usr/src/packages/BUILD/udev-015/klibc# cat utils/true.c #include <stdio.h> int main(void) { printf("blah\n"); return 0; } -- USB is for mice,

If I understand correctly, the Linux kernel has a function printk() designed for most printing functions where a string prefix determines where the message is seen. Would something like this be useful in Syslinux? As I see it, there's essentially 3 separate printing methods with an additional variation. Goals: - To keep data size smaller, avoid 2+ identical static strings (akin to {

Genec, your approach is also very insteresting, but I would like to present an alternative which will basically works with three priority states. ALTERNATIVE APPROACH: FILTER AND PRIORITIES ON PRINT. ----- Detail: Lower the priority number higher the importance of the message. ----- - default priority level: * Messages without a prefix will *always* take this priority level. ----- - debug