On Mon, Jun 6, 2016 at 12:15 PM, Cupertino Miranda <[email protected]> wrote: > Hi Dmitry, > > At the moment, for baremetal, I care only about libasan. > Considering that we do not have virtual memory addressing we will need to > hand set the address range and shadow memory through linker scripts. > > One of the difficulties I am having though the code is how to remove the > dependencies on system calls. > Any suggestion you can give on that respect? > > Theoretically, nothing in libasan looks like it needs system calls or even > an OS. However, code suggests that it depends on it. Am I wrong, and the OS > is really a requirement?
What exactly system calls do you mean? We developed it assuming an OS under us. I guess it should be possible to port it to baremetal, but it is just not what we assumed so it may require considerable changes. I think on baremetal you don't need most of the interceptors (e.g. for syscalls). And you can also strip lots of optional functionality like background thread and symbolizer. > On Monday, June 6, 2016 at 11:25:54 AM UTC+2, Dmitry Vyukov wrote: >> >> On Mon, Jun 6, 2016 at 10:15 AM, Cupertino Miranda >> <[email protected]> wrote: >> > Hi all, >> > >> > I am part of the team developing the GNU toolchain for the ARC >> > architecture >> > from Synopsys. Our toolchain supports two platforms: >> > - Baremetal - with libc support through newlib, >> > - Linux - currently using uClibc (glibc is being ported). >> > >> > Recently, we have noticed an increasingly interest in your tools from >> > our >> > customers/users and we would very much like to contribute with a port to >> > our >> > architecture. >> > >> > From all I read, it seems that support for any of the already supported >> > platforms should be relatively easy, considering that instrumentation >> > occurs >> > early in a generic phase (at least in GCC). >> > So we don't expect any big difficulty porting it to Linux. >> > >> > However, our problem and my questions are: >> > - How difficult or what would be the expected challenges making the >> > AddressSanitizer support a baremetal environment? >> > - Is an operating system a real requirement? >> > - Is anyone else working on this? >> >> >> Hi Cupertino, >> >> We've ported asan to Linux kernel: >> https://www.kernel.org/doc/Documentation/kasan.txt >> The main difficulty is mapping direct shadow memory. Reporting and >> interception of non-instrumented libraries is more or less trivial. >> >> We've also ported tsan to Linux kernel: >> https://github.com/google/ktsan >> It's far more challenging. Basically you need to rewrite all race >> detection logic and hook into scheduler and all synchronization >> primitives. >> >> Nobody is working on a baremetal implementation as far as I can tell. > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
