mirrors/cosmopolitan
1
0
Fork 0
mirror of https://github.com/jart/cosmopolitan.git synced 2025-01-31 19:43:32 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
cosmopolitan/libc/nexgen32e/zip.S

48 lines
2.5 KiB
ArmAsm
Raw Normal View History

Polish up repository and other revisions
2020-06-16 13:38:43 +00:00
/*-*- mode:unix-assembly; indent-tabs-mode:t; tab-width:8; coding:utf-8 -*-│
Initial import
2020-06-15 14:18:57 +00:00
│vi: set et ft=asm ts=8 tw=8 fenc=utf-8 :vi│
╞══════════════════════════════════════════════════════════════════════════════╡
│ Copyright 2020 Justine Alexandra Roberts Tunney │
│ │
Change license
2020-12-28 01:18:44 +00:00
│ Permission to use, copy, modify, and/or distribute this software for │
│ any purpose with or without fee is hereby granted, provided that the │
│ above copyright notice and this permission notice appear in all copies. │
Initial import
2020-06-15 14:18:57 +00:00
│ │
Change license
2020-12-28 01:18:44 +00:00
│ THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL │
│ WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED │
│ WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE │
│ AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL │
│ DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR │
│ PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER │
│ TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR │
│ PERFORMANCE OF THIS SOFTWARE. │
Initial import
2020-06-15 14:18:57 +00:00
╚─────────────────────────────────────────────────────────────────────────────*/
Remove more nonstandard stuff from cosmopolitan.h Fixes #61
2021-03-01 07:42:35 +00:00
#include "libc/macros.internal.h"
Add x86_64-linux-gnu emulator I wanted a tiny scriptable meltdown proof way to run userspace programs and visualize how program execution impacts memory. It helps to explain how things like Actually Portable Executable works. It can show you how the GCC generated code is going about manipulating matrices and more. I didn't feel fully comfortable with Qemu and Bochs because I'm not smart enough to understand them. I wanted something like gVisor but with much stronger levels of assurances. I wanted a single binary that'll run, on all major operating systems with an embedded GPL barrier ZIP filesystem that is tiny enough to transpile to JavaScript and run in browsers too. https://justine.storage.googleapis.com/emulator625.mp4
2020-08-25 11:23:25 +00:00
#include "ape/relocations.h"
#include "libc/zip.h"
Initial import
2020-06-15 14:18:57 +00:00
Get codebase completely working with LLVM You can now build Cosmopolitan with Clang: make -j8 MODE=llvm o/llvm/examples/hello.com The assembler and linker code is now friendly to LLVM too. So it's not needed to configure Clang to use binutils under the hood. If you love LLVM then you can now use pure LLVM.
2021-02-08 17:19:00 +00:00
// ZIP Central Directory.
Fix zip executables on MacOS Here's why we got those `Killed: 11` failures on MacOS after modifying the contentns of the redbean.com executable. If you were inserting a small file, such as a HelloWorld.html file, then InfoZIP might have decreased the size of the executable to less than what the Mach-O section had been expecting. That's because when zipobj.com put things like time zone data in the executable, it aligned each zip file entry on a 64-byte boundary, simply for the sake of readability in binary dumps. But when InfoZIP edited the file it would rewrite every entry using ZIP's usual 2-byte alignment. Thus causing shrinkage. The solution was to reconfigure the linker script so that zip file bits that get put into the executable at link-time, such as timezone data, aren't officially part of the executable image, i.e. we don't want the operating system to load that part. The original decision to put the linked zip files into the .data section was mostly made so that when the executable was run in its .com.dbg form it would still have the zip entries be accessible, even though there was tons of GNU debug data following the central directory. We're not going to be able to do that. The .com executable should be the canonical executable. We have really good tools for automatically attaching and configuring GDB correctly with debug symbols even when the .com is run. We'll have to rely on those in cases where zip embedding is used. See #53 See #54 See #68
2021-02-28 02:02:32 +00:00
.section .zip.3,"",@progbits
Add x86_64-linux-gnu emulator I wanted a tiny scriptable meltdown proof way to run userspace programs and visualize how program execution impacts memory. It helps to explain how things like Actually Portable Executable works. It can show you how the GCC generated code is going about manipulating matrices and more. I didn't feel fully comfortable with Qemu and Bochs because I'm not smart enough to understand them. I wanted something like gVisor but with much stronger levels of assurances. I wanted a single binary that'll run, on all major operating systems with an embedded GPL barrier ZIP filesystem that is tiny enough to transpile to JavaScript and run in browsers too. https://justine.storage.googleapis.com/emulator625.mp4
2020-08-25 11:23:25 +00:00
.hidden __zip_start
.globl __zip_start
.type __zip_start,@object
Initial import
2020-06-15 14:18:57 +00:00
__zip_start:
Add x86_64-linux-gnu emulator I wanted a tiny scriptable meltdown proof way to run userspace programs and visualize how program execution impacts memory. It helps to explain how things like Actually Portable Executable works. It can show you how the GCC generated code is going about manipulating matrices and more. I didn't feel fully comfortable with Qemu and Bochs because I'm not smart enough to understand them. I wanted something like gVisor but with much stronger levels of assurances. I wanted a single binary that'll run, on all major operating systems with an embedded GPL barrier ZIP filesystem that is tiny enough to transpile to JavaScript and run in browsers too. https://justine.storage.googleapis.com/emulator625.mp4
2020-08-25 11:23:25 +00:00
.previous/*
...
decentralized content
...
Fix zip executables on MacOS Here's why we got those `Killed: 11` failures on MacOS after modifying the contentns of the redbean.com executable. If you were inserting a small file, such as a HelloWorld.html file, then InfoZIP might have decreased the size of the executable to less than what the Mach-O section had been expecting. That's because when zipobj.com put things like time zone data in the executable, it aligned each zip file entry on a 64-byte boundary, simply for the sake of readability in binary dumps. But when InfoZIP edited the file it would rewrite every entry using ZIP's usual 2-byte alignment. Thus causing shrinkage. The solution was to reconfigure the linker script so that zip file bits that get put into the executable at link-time, such as timezone data, aren't officially part of the executable image, i.e. we don't want the operating system to load that part. The original decision to put the linked zip files into the .data section was mostly made so that when the executable was run in its .com.dbg form it would still have the zip entries be accessible, even though there was tons of GNU debug data following the central directory. We're not going to be able to do that. The .com executable should be the canonical executable. We have really good tools for automatically attaching and configuring GDB correctly with debug symbols even when the .com is run. We'll have to rely on those in cases where zip embedding is used. See #53 See #54 See #68
2021-02-28 02:02:32 +00:00
*/.section .zip.5,"",@progbits
Initial import
2020-06-15 14:18:57 +00:00
__zip_end:
Add x86_64-linux-gnu emulator I wanted a tiny scriptable meltdown proof way to run userspace programs and visualize how program execution impacts memory. It helps to explain how things like Actually Portable Executable works. It can show you how the GCC generated code is going about manipulating matrices and more. I didn't feel fully comfortable with Qemu and Bochs because I'm not smart enough to understand them. I wanted something like gVisor but with much stronger levels of assurances. I wanted a single binary that'll run, on all major operating systems with an embedded GPL barrier ZIP filesystem that is tiny enough to transpile to JavaScript and run in browsers too. https://justine.storage.googleapis.com/emulator625.mp4
2020-08-25 11:23:25 +00:00
.long kZipCdirHdrMagic # magic
.short 0 # disk
.short 0 # starting disk
Generate ZIP files the same way as Windows
2021-03-01 14:24:11 +00:00
.short v_zip_records # number of records on disk
Add x86_64-linux-gnu emulator I wanted a tiny scriptable meltdown proof way to run userspace programs and visualize how program execution impacts memory. It helps to explain how things like Actually Portable Executable works. It can show you how the GCC generated code is going about manipulating matrices and more. I didn't feel fully comfortable with Qemu and Bochs because I'm not smart enough to understand them. I wanted something like gVisor but with much stronger levels of assurances. I wanted a single binary that'll run, on all major operating systems with an embedded GPL barrier ZIP filesystem that is tiny enough to transpile to JavaScript and run in browsers too. https://justine.storage.googleapis.com/emulator625.mp4
2020-08-25 11:23:25 +00:00
.short v_zip_records # records
.long v_zip_cdirsize # size of central directory
.long RVA(__zip_start) # central directory offset
.short v_zip_commentsize # comment size
.endobj __zip_end,globl,hidden
.weak v_zip_records
.weak v_zip_cdirsize
.weak v_zip_commentsize
.previous
Reference in a new issue Copy permalink