similar to: ASan port for Myriad RTEMS

Hi Walter, I've done a first quick scan. Overall looks reasonable, but I'd like to try reducing the number of newly introduced platform-specific ifs. Vitaly, please also take a look (once my initial comments are addressed). One outstanding issue is your problem with initialization vs checking, which requires you to insert so many ifs. Is there any chance you can avoid this? If you

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 a prototype in golang that just spins up an instance of llvm-symbolizer

Hi Jake. Thanks for the info. Where can I keep up to date on the symbolizer status? Our symbolizer is provided 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

Hi Kostya. Thanks for the quick feedback. I will work on addressing your comments. In regard to initialization checks, I can eliminate most of them by initializing the shadow memory very early, but I still need to do something in two places, __asan_handle_no_return and GetFakeStackFast. Would it be ok to have guards for those two places only? Walter On Fri, May 4, 2018 at 6:10 PM Kostya

On Fri, May 4, 2018 at 6:29 PM Walter Lee <waltl at google.com> wrote: > Hi Kostya. Thanks for the quick feedback. I will work on addressing your > comments. > > In regard to initialization checks, I can eliminate most of them by > initializing the shadow memory very early, This will be a very good way to handle this. > but I still need to do something > in two

On RAM... You chose the 32-byte shadow granularity to reduce the RAM overhead, but I am afraid this will actually increase it due to extra alignment requirements, especially if an average allocation on your typical application is small. The pointers are 32-bit, right? Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN.

Hi, Would anyone be interested in developing a LatticeMico32 backend in LLVM? LatticeMico32 [1] is an open source microprocessor core designed by Lattice Semiconductor and typically used in FPGAs. It is comparable to the Microblaze processor that you already support. It is already supported by GNU Binutils and GCC (4.5+). It is used by the Milkymist [2] and RTEMS [3] projects. The Milkymist

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:08.realpath Security Advisory The FreeBSD Project Topic: Single byte buffer overflow in realpath(3) Category: core Module: libc Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:08.realpath Security Advisory The FreeBSD Project Topic: Single byte buffer overflow in realpath(3) Category: core Module: libc Announced:

Am 04.02.2016 um 14:46 schrieb Roland Mainz: > On Thu, Feb 4, 2016 at 1:40 PM, Christian Mauderer > <christian.mauderer at embedded-brains.de> wrote: >> I am searching a SSH server for remote administration of an embedded >> application running on RTEMS (https://www.rtems.org). This environment >> has neither virtual memory nor user and kernel space. So this is like

Hello, I am searching a SSH server for remote administration of an embedded application running on RTEMS (https://www.rtems.org). This environment has neither virtual memory nor user and kernel space. So this is like an application running in kernel mode only. Would it be possible to run (a very basic version of) OpenSSH in such an environment using e.g. threads instead of forking new

Hi, I'd like to load with pxelinux an RTEMS executable file, the format is ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, strtipped Can someone tell me if there is a way to load it with PXElinux. When I try to do it, the error message is : invalid or corrupt kernel image Thanks for your help. Regards. Stephane ARQUER

Just bringing that up as I did not get any reply so far. Thanks, Sébastien On Tuesday 18 May 2010 18:38:41 Sébastien Bourdeauducq wrote: > Hi, > > Would anyone be interested in developing a LatticeMico32 backend in LLVM? > > LatticeMico32 [1] is an open source microprocessor core designed by Lattice > Semiconductor and typically used in FPGAs. It is comparable to the >

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

Op 20-09-2007 om 08:31 schreef St?phane ARQUER: > "previous" > > [ 'elf.c32' booting a RTEMS ELF binary ] > > - P4 2GHz 512M with a 3c905c PXE v2.20 > PXELINUX doesn't work with this one > > - P4 3GHz 2048M with an Intel 82573L gigabit eth PXE > PXELINUX works on this machine > > - HP kayak P3 866MHz with PXE v2.20 > PXELINUX doesn't

Hi, I have a question about compiling Ogg/Vorbis. As I plan to have the code run on the LEON/SPARC CPU so I have to use sparc-rtems-gcc, sparc-rtems-ld, sparc-rtems-ranlib. Now, in order to compile the libs, e.g., libogg, I have to create my own Makefile like this: PROG=bitwise framing CC=sparc-rtems-gcc AR=sparc-rtems-ar RANLIB=sparc-rtems-ranlib CFLAGS=-rtems -msoft-float -Wall -W -g

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:08.realpath Security Advisory The FreeBSD Project Topic: Single byte buffer overflow in realpath(3) Category: core Module: libc Announced:

Hello there. I tried make update using the following stable-supfile: *default base=/usr *default prefix=/usr *default release=cvs tag=RELENG_4 *default delete use-rel-suffix and my two nearest Russian CVS mirrors showed no changes in realpath. Heck, I downloaded the patch and said in /usr/src: # patch < realpath.patch so it was rejected. Then I looked into realpath.c's revision and

LLVM already implements its 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

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