Project Description

Valgrind currently lacks support for 80-bit extended precision floating point arithmetic on x86_64 (long double). The current implementation uses 64-bit arithmetic instead, which means that programs running on x86_64 with "long double" give different results when running under Valgrind and natively. People were asking for support for this since like forever, but to date nobody went on implementing it. It's a project for a year, unless somebody has time to work on it full time, but one has to start somewhere. :-)

Goal for this Hackweek

  • figure out what needs to be changed in the current implementation
  • figure out what are the possibilities of testing it
  • compile a list of instructions to be implemented
  • write a test program exercising every instruction to be implemented individually
    • must demonstrate no loss of accuracy
    • example: none/tests/amd64/sse4-64.c
  • clone valgrind repo and start commiting

The result of the hackweek should be the test case and some writeup on what else needs to happen.

Resources

  • https://bugs.kde.org/show_bug.cgi?id=197915
  • https://sourceware.org/git/?p=valgrind.git
  • https://en.wikipedia.org/wiki/X87
  • https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-1-manual.pdf
  • https://refspecs.linuxbase.org/elf/x86_64-SysV-psABI.pdf
  • https://valgrind.org/docs/manual/manual-core.html#manual-core.limits
  • https://en.wikibooks.org/wiki/X86Assembly/FloatingPoint

Looking for hackers with the skills:

c x86_64 valgrind assembly floating-point x86

This project is part of:

Hack Week 23

Activity

  • about 2 years ago: mbrugger liked this project.
  • about 2 years ago: dfaggioli liked this project.
  • about 2 years ago: mschreiner liked this project.
  • about 2 years ago: mschreiner joined this project.
  • about 2 years ago: wfrisch liked this project.
  • about 2 years ago: e_bischoff liked this project.
  • about 2 years ago: mfranc started this project.
  • about 2 years ago: mfranc added keyword "x86" to this project.
  • about 2 years ago: mfranc added keyword "floating-point" to this project.
  • about 2 years ago: mfranc removed keyword floatingpointarithmetic from this project.
  • about 2 years ago: mfranc added keyword "floatingpointarithmetic" to this project.
  • about 2 years ago: mfranc added keyword "assembly" to this project.
  • about 2 years ago: mfranc added keyword "valgrind" to this project.
  • about 2 years ago: mfranc added keyword "x86_64" to this project.
  • about 2 years ago: mfranc added keyword "c" to this project.
  • about 2 years ago: mfranc originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    x64id: An x86/x64 instruction disassembler by m.crivellari

    Description

    This is an old side project. An x86/x64 machine code decoder. It is useful to get instructions' length and identify each of its fields.

    Example:

    C7 85 68 FF FF FF 00 00 00 00

    This is the instruction:

    MOV DWORD PTR SS:[LOCAL.38],0

    What follows are some of the information collected by the disassembler, based on the specific instruction:

    RAW bytes (hex): C7 85 68 FF FF FF 00 00 00 00
    Instr. length: 10
    Print instruction fields:
            Located Prefixes 0:
    
            OP: 0xC7
            mod_reg_rm: 0x85
            disp (4): 0xFFFFFF68
            Iimm: 0x0
    

    Lacks the mnemonic representation: from the previous machine code is not able to produce the "MOV..." instruction, for example.

    Goals

    The goal is almost easy: partially implement the mnemonic representation. I have already started during the weekend, likely tomorrow I will push the branch!

    Resources

    Progress

    Let's consider this example:

    [...other bytes...] 43 89 44 B5 00 01 00 [...other bytes...]
    


    Port OTPClient to GTK >= 4.18 by pstivanin

    Project Description

    OTPClient is currently using GTK3 and cannot easily be ported to GTK4. Since GTK4 came out, there have been quite some big changes. Also, there are now some new deprecation that will take effect with GTK5 (and are active starting from 4.10 as warnings), so I need to think ahead and port OTPClient without using any of those deprecated features.

    Goal for this Hackweek

    • fix the last 3 opened issues (https://github.com/paolostivanin/OTPClient/issues/402, https://github.com/paolostivanin/OTPClient/issues/404, https://github.com/paolostivanin/OTPClient/issues/406) and release a new version
    • continue the rewrite from where we left last year
    • if possible, finally close this 6 years old issue: https://github.com/paolostivanin/OTPClient/issues/123


    Add a machine-readable output to dmidecode by jdelvare

    Description

    There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.

    Goals

    Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.


    pudc - A PID 1 process that barks to the internet by mssola

    Description

    As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:

    • The backend is written in a mixture of C and RISC-V assembly.
    • The backend is actually PID1 (for real, not within a container).
    • We poll and parse incoming HTTP requests ourselves.
    • The frontend is a mere HTML page with htmx.

    The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.

    I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.

    Goals

    • Have a better understanding of different Linux features from user space down to the kernel internals.
    • Most importantly: have fun.

    Resources


    Improve the picotm Transaction Manager by tdz

    Picotm is a system-level transaction manager. It provides transactional semantics to low-level C operations, such as

    • memory access,
    • modifying data structures,
    • (some) file I/O, and
    • common interfaces from the C Standard Library and POSIX.

    Picotm also handles error detection and recovery for all it's functionality. It's fully modular, so new functionality can be added.

    For the Hackweek, I want to dedicate some time to picotm. I want to finish some of the refactoring work that I have been working on. If there's time left, I'd like to investigate two-phase commits and how to support them in picotm.

    Picotm is available at http://picotm.org/.


    x64id: An x86/x64 instruction disassembler by m.crivellari

    Description

    This is an old side project. An x86/x64 machine code decoder. It is useful to get instructions' length and identify each of its fields.

    Example:

    C7 85 68 FF FF FF 00 00 00 00

    This is the instruction:

    MOV DWORD PTR SS:[LOCAL.38],0

    What follows are some of the information collected by the disassembler, based on the specific instruction:

    RAW bytes (hex): C7 85 68 FF FF FF 00 00 00 00
    Instr. length: 10
    Print instruction fields:
            Located Prefixes 0:
    
            OP: 0xC7
            mod_reg_rm: 0x85
            disp (4): 0xFFFFFF68
            Iimm: 0x0
    

    Lacks the mnemonic representation: from the previous machine code is not able to produce the "MOV..." instruction, for example.

    Goals

    The goal is almost easy: partially implement the mnemonic representation. I have already started during the weekend, likely tomorrow I will push the branch!

    Resources

    Progress

    Let's consider this example:

    [...other bytes...] 43 89 44 B5 00 01 00 [...other bytes...]
    


    pudc - A PID 1 process that barks to the internet by mssola

    Description

    As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:

    • The backend is written in a mixture of C and RISC-V assembly.
    • The backend is actually PID1 (for real, not within a container).
    • We poll and parse incoming HTTP requests ourselves.
    • The frontend is a mere HTML page with htmx.

    The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.

    I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.

    Goals

    • Have a better understanding of different Linux features from user space down to the kernel internals.
    • Most importantly: have fun.

    Resources