search for: nlist_64

As part of our work on LLD for Mach-O, we’ve observed that the object files produced by LLVM don’t always have aligned nlist_64 entries. For context, nlist_64 is the 64-bit symbol table entry structure for Mach-O, and the symbol table is an array of nlist_64 entries. nlist_64 has an 8 byte member, so it should be 8-byte aligned, but we’ve seen object files where the symbol table only has a 4-byte alignment. I don't kno...

...a7443/libkern/libkern/OSByteOrder.h#L109-L117 From: David Blaikie <dblaikie at gmail.com> Date: Tuesday, May 26, 2020 at 11:25 AM To: Shoaib Meenai <smeenai at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Emitting aligned nlist_64 structures for Mach-O in MC I'd have figured if ld64 is able to handle this correctly (are you sure ld64 has UB in this situation when the lists are underaligned? perhaps it has utilities for doing underaligned reads, etc?) it's probably important for lld to handle them too - old object fi...

...some of the symbols present in my binary (memory allocator, mmap). Interposition support is somewhat lacking in the Mach-O toolchain and runtime linker despite the Mach-O format technically supporting what I need (N_INDR and N_WEAK_DEF). > > - https://developer.apple.com/documentation/kernel/nlist_64 <https://developer.apple.com/documentation/kernel/nlist_64> Dyld does not generally use nlists at runtime except for things like dladdr(), and has not for the last 10 years or so. Instead dyld uses a trie to publish exports, and and a small byte code language to describe binding imports. We s...

> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Folks, > > I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working

When I make a simple test program and call abort() and use LLDB to debug it, it has address-to-line mapping. If I then delete the .o file and run LLDB again, it loses the address-to-line mapping. So there must be DWARF info, or otherwise address-to-line info in the .o file. I'm parsing the MACH-O executable, which has a LC_SYMTAB entry, and one of the entries is the file path of the .o file.

...r the next symbol start address, and COFF holds the symbol sizes in auxiliary info that follows each symbol entry. See also http://www.delorie.com/djgpp/doc/coff/symtab.html and https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/c/tag/nlist_64 -- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/ab0d5d8b/attachment.html>

Hi Folks, I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say

...OQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=7isNRRG84wFLU9ztTKYIXpp2tc_k91DwDH6bOpuOEsQ&e=> > and > https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/index.html#//apple_ref/c/tag/nlist_64 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_library_mac_documentation_DeveloperTools_Conceptual_MachORuntime_index.html-23__apple-5Fref_c_tag_nlist-5F64&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSf...