search for: hosek

Petr Hosek via 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 &...

On Mon, Aug 31, 2020 at 4:38 PM Petr Hosek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There are several options, I've looked at couple of them and the one I > like the most so far is https://github.com/yhirose/cpp-httplib for a few > reasons: > > * It's MIT licensed. > * It supports Linux, macOS and...

...gt; I'd imagine avoiding writing such a thing from scratch would be desirable, > but that the decision might depend somewhat on what libraries out there > you/we would consider including, what their licenses and further > dependencies are. > > On Mon, Aug 31, 2020 at 4:22 PM Petr Hosek via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> We're considering implementing [debuginfod]( >> https://sourceware.org/elfutils/Debuginfod.html) library in LLVM. >> Initially, we'd like to start with the client implementation, which would >> enab...

...om/splunk/pion) to build a HTTP server interface, but since it seems pretty unmaintained I am not sure I would recommend it. I have heard good things about https://github.com/matt-42/lithium/ but have no direct experience of using / building it. Thanks, Tobias On Tue, Sep 1, 2020 at 2:22 AM Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > These are the ones I found so far: > > * [libmicrohttpd](https://www.gnu.org/software/libmicrohttpd/) is used by elfutils' debuginfod, but it's LGPL licensed. > * [libcURL](https://curl.haxx.se/libcurl/) would be an o...

While trying to compile an existing codebase which uses handwritten assembly with LLVM, I ran into an issue around using backward references in assembly absolute expressions. A simple example can be the following snippet: _foo: .fill 0x100 _bar: .fill _bar - _foo _baz: .fill 0x100 While gas compiles this snippet without any errors, the integrated assembler throws an error: expected

When committing changes on behalf of other contributors, I've started setting the author in Git to be the change author. I think that's better for attribution than just including "Patch By: username" in the message which is default for arc, especially now that we're finally using Git. However, I've noticed that when the change breaks bots, emails are sent only to the

> On Sep 24, 2020, at 23:52, Petr Hosek <phosek at chromium.org> wrote: > > Using more interface libraries is definitely the right direction and a modern way to use CMake. I'm not sure if we can get to a single interface target since different runtimes have different requirements. I was assuming that we would have one in...

...ot, but tried it and I get this: CMake Error at projects/libcxx/CMakeLists.txt:361 (message): LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on OS X Why is it not supported? If I manually embed libc++abi.a inside libc++.a it seems to work. Thanks! ardi On Mon, Oct 1, 2018 at 4:20 AM Petr Hosek <phosek at chromium.org> wrote: > > You can use LIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON CMake option to statically link libc++abi into libc++.a. You can also use LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY=OFF to disable statically linking libc++abi into libc++.so (i.e. libc++abi will only...

On 10 January 2018 at 21:06, Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It seems like this has already been set up for all the projects except for > libunwind. Can we create a Differential repository for it as well? I'll be > happy to update its .arcconfig once that's done. Additionally, it migh...

On Fri, Jun 2, 2017 at 1:01 PM Sean Silva <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 add...

...rom the "not largely affected" camp: > > - the churn doesn't feel that major for HAS_ and ... > - the uniformity feels nice > > and in general feels nice and in pursuit of the longer term goals here. > > -eric > > On Tue, Sep 22, 2020 at 11:58 AM Petr Hosek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > We've been using the runtimes build for a while now and we're very happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend m...

On Wed, May 17, 2017 at 1:32 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, May 17, 2017 at 1:11 PM, Petr Hosek <phosek at chromium.org> wrote: > >> The motivation is not only memory savings but also security: >> can-never-be-written is strictly better than RELRO in all cases. The >> biggest win is when .dynamic is the sole reason for having a writable >> segment at all. The...

We're considering implementing [debuginfod]( https://sourceware.org/elfutils/Debuginfod.html) library in LLVM. Initially, we'd like to start with the client implementation, which would enable debuginfod support in tools like llvm-symbolizer, but later we'd also like to provide LLVM-based debuginfod server implementation. debuginfod uses HTTP and so we need an HTTP library, ideally one

...pport it upstream as needed, especially if there is some particular problem you're looking to solve by removing this code. Feel free to contact me directly as well (aside from the usual channels like this list of course) if you want more on NaCl or PNaCl. On Sat, Apr 18, 2020 at 10:25 PM Petr Hosek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sat, Apr 18, 2020 at 7:43 PM Fangrui Song via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi all, >> >> LLVM/Clang supports an OS called 'NaCl' (llvm/include/llvm/ADT/Triple.h). >> It...

On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: > In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects,...

On Tue, Dec 19, 2017 at 12:33 PM Jonathan Roelofs <jonathan at codesourcery.com> wrote: > On 12/19/17 12:53 PM, Petr Hosek wrote: > > On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs < > jonathan at codesourcery.com> wrote: > >> On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote: >> > Today, there're two different locations for runtimes files within >> > Clang's install...

...g and also an easy way to screw things up. Furthermore, the current standalone builds add complexity to the projects, because they require the ability to point to arbitrary headers/libraries from the other projects, when we really always want to point to the just-built ones. Relationship with Petr Hosek's "Runtimes" build --------------------------------------------------------------- What I'm proposing isn't a replacement for itl. The "Runtimes" build can be seen as a driver that sets up the individual libc++/libc++abi/libunwind builds with the just-built toolchain...

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

> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org <mailto:phosek at chromium.org>>: > You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs. IMO, a more thorough solution would be switching to LLD (the gold linker might work few years ago, but now even gold will take me ne...

On 03/25/2020 06:20 AM, Louis Dionne wrote: > > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subpr...