search for: fuchsia

...ts own version of almost all of binutils. The exceptions to this rule are objcopy and strip. This is a proposal to implement an llvm version of objcopy/strip to complete llvm’s binutils. Several projects only use gnu binutils because of objcopy/strip. LLVM itself uses objcopy in fact. Chromium and Fuchsia currently use objcopy as well. If you want to distribute your build tools this is a problem due to licensing. It’s also a bit of a blemish on LLVM because LLVM could be made more self sufficient if there was an llvm version of objcopy. Additionally Chromium is one of the popular benchmarks for LLVM...

...ovided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have...

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have...

...> > I'm not even sure if it is strictly better to make .dynamic read-only by > default is better than relro. It seems almost the same to me. What are > attack scenario you can think of in which you can exploit only when > .dynamic sections are read-only from beginning? > Maybe Fuchsia OS does something special for executable that contain > read-only sections only? > I'd be interested in this as well, CFI relies on relro for its vtable protection to work. Is the issue just the window of opportunity between mapping the pages and protecting them? > > LLD already...

...<chisophugis at gmail.com> wrote: > On Thu, Jun 1, 2017 at 8:47 PM, Petr Hosek via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This is a followup to the discussion that started in D28791. To provide >> the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle >> symbol is mandated by C++ ABI with a value which is an address in one of >> the object's segments, and as such this symbol has to be included >> statically and cannot be a part of a shared library. Different systems >> provide it differently: >> &g...

This is a followup to the discussion that started in D28791. To provide the context, we need a way to provide __dso_handle in Fuchsia. __dso_handle symbol is mandated by C++ ABI with a value which is an address in one of the object's segments, and as such this symbol has to be included statically and cannot be a part of a shared library. Different systems provide it differently: 1. On GNU/Linux systems, it's defined in c...

...ps://reviews.llvm.org/D46457 [asan] Add a magic shadow value for shadw gap https://reviews.llvm.org/D46459 [asan] On RTEMS, checks for asan_inited before entering ASan run-time https://reviews.llvm.org/D46461 [asan] Set flags appropriately for RTEMS https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to be reused by Myriad RTEMS https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion when reporting Mmap failure https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to support thread rest...

...is fairly small for exploitability, but not negligible. LLD already has several command-line options that are not supported by or are different from ld or gold, so this wouldn't be the first one (and probably not the last). If LLD supported per-OS configuration, we would make this default for Fuchsia and wouldn't need the new option, but since these don't exists, it's something we would handle through the Clang driver. On Tue, May 16, 2017 at 7:12 PM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thank you for confirming. But one page is too small, no? I t...

Hi, I'm working on cross-compiling llvm and sub-projects to dynamically build Clang toolchain and associated libraries for an embedded project. I'm starting with this mailing list, as I see the pattern using "config-ix.cmake" a common one; it's found in all the sub-projects. For those that are not aware, in CMake the standard approach for dealing with unique toolchains,

...s mapped to a >> PT_GNU_RELRO section. PT_GNU_RELRO sections are not shared between >> instances of a executable however. It would be a nice optimization to share >> the .dynamic section of an application where possible. In particular we >> would like to have this option for Fuchsia. Other dynamic linkers, like >> musl, already have some support for this on non-MIPS targets as seen here: >> http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1629. In >> particular the DT_DEBUG_INDIRECT entry is recognized. >> >> This change would refactor code...

...TAPI [1]: Stubbing used to reduce SDK size and improve build times. - Oracle’s Solaris OS linker [2]: Stubbing used to improve build times, and improve robustness of build system (against dependency cycles and race conditions). - Google’s Bazel [3]: Stubbing used to improve build times. - Google’s Fuchsia [4] [5]: Stubbing used to improve build times. - Android NDK: Stubbing used to reduce size of native sdk, control exported symbols, and improve build times. Somewhat tangentially, a tool called libabigail [6] provides utilities for tracking changes relevant to ELF files in a meaningful way. One of...

Hi, On Tue, 6 Oct 2020 at 18:31, David Blaikie <dblaikie at gmail.com> wrote: > > My 2c would be to push back a bit more on the "let's not have a machine readable format, but instead parse the human readable format" - it seems like that's going to make the human readable format/parsing fairly brittle/hard to change (I mean, having the parser in tree will help, for

.../C++ functions. Up until now, Scudo was mostly used (as far as I can tell) by linking the library (dynamically or statically) to binaries, thus overriding the platform’s C/C++ library allocation functions. A new usage scenario has emerged: replacing the actual libc allocator on a platform (namely Fuchsia). The current organization of the code, and some design choices, do not fit the requirements for such a use case (as expressed by Fuchsia, but legitimate points for all use): the code should be “production ready”, ideally small and self contained, carefully reviewed for potential performance impact...

...SVCRT would be useful for people using clang on Windows as well. On Mon, Jun 24, 2019 at 3:38 PM Jake Ehrlich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > disclaimer: I work at Google so don't take my +1 as an independent vote forward. > > We would like to use this on Fuchsia and I am particularly interested in creating a dynamic linking library for ELF with Roland McGrath's guidance. We spoke about creating a library for writing dynamic linkers internally and I don't see why this can't be upstreamed. > > On Fuchsia we critically need support for AArch...

...llvm-dev <llvm-dev at lists.llvm.org> writes: > One of the design principles we're trying to follow is to make everything > read-only, unless it has be writable. The only reason for .dynamic to be > writable is DT_DEBUG which is something we never intend to support. FWIW in > Fuchsia all we need is a read-only .dynamic without emitting DT_DEBUG > altogether, but we wanted to make sure that this flag is also usable > elsewhere hence implementing DT_DEBUG_INDIRECT which is already supported > by musl as Jake pointed out. It might be easier to have an option for making ....

...nux` it will work. You passed `-target -i386`, >which is a triple with no OS, so Clang is doing something arbitrary. Grepping >Clang sources shows that this flag is handled in an OS-specific manner: > >$ git grep -i fuse_init_array ../clang/lib/Driver/ >../clang/lib/Driver/ToolChains/Fuchsia.cpp:  if (DriverArgs.hasFlag >(options::OPT_fuse_init_array, >../clang/lib/Driver/ToolChains/Gnu.cpp:  if (DriverArgs.hasFlag >(options::OPT_fuse_init_array, >../clang/lib/Driver/ToolChains/NetBSD.cpp:  if (DriverArgs.hasFlag >(options::OPT_fuse_init_array, >../clang/lib/Driver/To...

...prove build times. > > - Oracle’s Solaris OS linker [2]: Stubbing used to improve build > > times, and improve robustness of build system (against dependency > > cycles and race conditions). > > - Google’s Bazel [3]: Stubbing used to improve build times. > > - Google’s Fuchsia [4] [5]: Stubbing used to improve build times. > > - Android NDK: Stubbing used to reduce size of native sdk, control > > exported symbols, and improve build times. > > > > Somewhat tangentially, a tool called libabigail [6] provides utilities > > for tracking changes...

...racle’s Solaris OS linker [2]: Stubbing used to improve build >> >> times, and improve robustness of build system (against dependency >> >> cycles and race conditions). >> >> - Google’s Bazel [3]: Stubbing used to improve build times. >> >> - Google’s Fuchsia [4] [5]: Stubbing used to improve build times. >> >> - Android NDK: Stubbing used to reduce size of native sdk, control >> >> exported symbols, and improve build times. >> >> >> >> Somewhat tangentially, a tool called libabigail [6] provides utilities...

...nd improve build times. >> - Oracle’s Solaris OS linker [2]: Stubbing used to improve build >> times, and improve robustness of build system (against dependency >> cycles and race conditions). >> - Google’s Bazel [3]: Stubbing used to improve build times. >> - Google’s Fuchsia [4] [5]: Stubbing used to improve build times. >> - Android NDK: Stubbing used to reduce size of native sdk, control >> exported symbols, and improve build times. >> >> Somewhat tangentially, a tool called libabigail [6] provides utilities >> for tracking changes relev...

...ementptr inbounds ([3 x i32], [3 x i32]* @__sancov_gen_.1, i64 0, i64 0)) ... ``` This can lead to a discarded section error for `__sancov_guards` when linking this with another TU that contains the prevalent comdat for $ _ZN3Foo10public_fooEv. We see this here <https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket.appspot.com/8880544155798188656/+/steps/build/0/steps/build_fuchsia/0/steps/ninja/0/steps/zircon/0/logs/raw_io.output_failure_raw_summary_/0> when building with sancov. The underlying issue seems to be that symbols in a comdat group that aren’t the key symbol are bein...