Page MenuHomePhabricator

pcc (Peter Collingbourne)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 28 2012, 2:34 PM (402 w, 6 d)

Recent Activity

Yesterday

pcc added inline comments to D87739: scudo: Add an API for disabling memory initialization per-thread..
Thu, Sep 17, 2:47 PM · Restricted Project

Wed, Sep 16

pcc added inline comments to D87739: scudo: Add an API for disabling memory initialization per-thread..
Wed, Sep 16, 7:26 PM · Restricted Project
pcc updated the diff for D87739: scudo: Add an API for disabling memory initialization per-thread..

Fix bug, add test, address review comment

Wed, Sep 16, 7:25 PM · Restricted Project
pcc added inline comments to D87739: scudo: Add an API for disabling memory initialization per-thread..
Wed, Sep 16, 5:01 PM · Restricted Project
pcc added inline comments to D87739: scudo: Add an API for disabling memory initialization per-thread..
Wed, Sep 16, 11:51 AM · Restricted Project

Tue, Sep 15

pcc added a comment to D87739: scudo: Add an API for disabling memory initialization per-thread..

This is the patch that I've been using to stress test my implementation:

diff --git a/compiler-rt/lib/scudo/standalone/combined.h b/compiler-rt/lib/scudo/standalone/combined.h
index 6c39b8f361e7..54ea5f487ac9 100644
--- a/compiler-rt/lib/scudo/standalone/combined.h
+++ b/compiler-rt/lib/scudo/standalone/combined.h
@@ -9,6 +9,8 @@
 #ifndef SCUDO_COMBINED_H_
 #define SCUDO_COMBINED_H_
Tue, Sep 15, 9:09 PM · Restricted Project
pcc requested review of D87739: scudo: Add an API for disabling memory initialization per-thread..
Tue, Sep 15, 8:59 PM · Restricted Project

Thu, Sep 10

pcc committed rGd876c7c8ec53: scudo: Remove the THREADLOCAL macro. (authored by pcc).
scudo: Remove the THREADLOCAL macro.
Thu, Sep 10, 7:17 PM
pcc closed D87478: scudo: Remove the THREADLOCAL macro..
Thu, Sep 10, 7:16 PM · Restricted Project
pcc committed rG84c2c4977dfe: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS… (authored by pcc).
scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS…
Thu, Sep 10, 7:16 PM
pcc closed D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
Thu, Sep 10, 7:16 PM · Restricted Project
pcc added a comment to D87478: scudo: Remove the THREADLOCAL macro..

This was tested with clang but I also tried g++ 9.3.0 and it compiled there. Beyond that I reckon we should just rely on bots.

Thu, Sep 10, 6:56 PM · Restricted Project
pcc added inline comments to D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
Thu, Sep 10, 6:50 PM · Restricted Project
pcc updated the diff for D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
  • Address review comments
Thu, Sep 10, 6:49 PM · Restricted Project
pcc updated the diff for D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
  • Renamed the function per feedback on the Android review
Thu, Sep 10, 1:54 PM · Restricted Project
pcc added a comment to D87418: [LLD] Allow configuring default ld.lld backend.

How widespread are these build systems that parse help output? (Given that it took until now to discover them, I'd venture "not very".) Maybe it would be better to fix them to explicitly pass -m and/or do something that doesn't rely on parsing help output (e.g. just try the flag and see whether it fails).

Thu, Sep 10, 1:35 PM · Restricted Project, lld
pcc requested review of D87478: scudo: Remove the THREADLOCAL macro..
Thu, Sep 10, 12:39 PM · Restricted Project
pcc added inline comments to D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
Thu, Sep 10, 12:32 PM · Restricted Project
pcc updated the diff for D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
  • Address review comments
Thu, Sep 10, 12:31 PM · Restricted Project
pcc added a comment to D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.

Where is the implementation of getPlatformTlsSlot?

Thu, Sep 10, 12:25 PM · Restricted Project

Wed, Sep 9

pcc requested review of D87420: scudo: Introduce a new mechanism to let Scudo access a platform-specific TLS slot.
Wed, Sep 9, 3:33 PM · Restricted Project

Thu, Sep 3

pcc added a comment to D87095: [Triple][MachO] Define "arm64e", an AArch64 subarch for Pointer Auth..

Hi, thanks for getting started on upstreaming this!

Thu, Sep 3, 11:00 AM · Restricted Project, Restricted Project

Tue, Aug 25

pcc accepted D75655: [Docs] Document -lto-whole-program-visibility.

Thanks and sorry for the delay.

Tue, Aug 25, 6:03 PM · Restricted Project
pcc added a comment to D75655: [Docs] Document -lto-whole-program-visibility.

I think that the part of the description beginning "This can be used when..." is somewhat misleading since you could pretty much say the same thing about specifying -fvisibility=hidden -fwhole-program-vtables at compile time.

Tue, Aug 25, 4:20 PM · Restricted Project

Mon, Aug 24

pcc added a comment to D84414: [RISCV] Support Shadow Call Stack.

FWIW, on aarch64 we decided to make -fsanitize=shadow-call-stack require the x18 reservation (instead of implying it) to try to avoid ABI mismatch problems. That is, it should be safe to mix and match code compiled with and without -fsanitize=shadow-call-stack. If we make -fsanitize=shadow-call-stack imply the x18 reservation, it makes it more likely that someone will accidentally build and link in incompatible code that does not reserve x18.

Mon, Aug 24, 11:36 AM · Restricted Project, Restricted Project

Wed, Aug 19

pcc committed rGa208ad5ddb5b: sanitizer_common: Use void* for madvise first argument on Solaris. (authored by pcc).
sanitizer_common: Use void* for madvise first argument on Solaris.
Wed, Aug 19, 10:56 AM
pcc closed D86166: sanitizer_common: Use void* for madvise first argument on Solaris..
Wed, Aug 19, 10:56 AM · Restricted Project

Aug 18 2020

pcc added a comment to D86166: sanitizer_common: Use void* for madvise first argument on Solaris..
In D86166#2224751, @ro wrote:
In D86166#2224690, @pcc wrote:

@ro On D85870 you mentioned that the declaration has been changed in Solaris 11.4 to use void * which causes a build break on 11.4 due to the incompatible declaration. I checked illumos and it looks like their declaration still has caddr_t, although the comment above this declaration implies that that shouldn't matter because the system's declaration isn't visible. But what about older versions of Solaris? Presumably they still have a declaration with caddr_t so I imagine the build would break with an incompatible declaration error there. Or do we not care about older versions?

As was discussed in D84046, Solaris doesn't need an explicit declaration at all: with __EXTENSIONS__ defined, a declaration of madvise will be visible without doing anything special.

However, on Illumos with _XOPEN_SOURCE defined (as g++ does on Solaris), there is no way to make an madvise declaration visible. So on Illumos, it doesn't matter if it uses void * or caddr_t since there can be no conflict with a system declaration. However the declaration currently needs to agree with the Solaris one to avoid the build breakage.

Part of the trouble is that we currently cannot distinguish between Solaris and Illumos at all at compile time; I have a patch to define __illumos__ based on uname -o for cases where it's difficult otherwise. All a royal mess, but done for the benefit of Illumos, not for not caring about it.

With respect to other older versions of Solaris, the only one even remotely interesting (and the oldest one I still test in GCC) is 11.3. I have a bunch of patches to at least allow LLVM to compile, but there are so many issues (ld not wrapping sections in __start_<sec>/__stop_<sec> symbols, lack of __cxa_atexit, lack of fmemopen, lack of constructor priority support, and that's just the tip of the iceberg) that I strongly doubt there's any value in trying to pursue this further. In fact the 11.3 madvise declaration still using caddr_t prompted me to do the __illumos__ patch so an Illumos-only declaration wouldn't interfere with Solaris.

Aug 18 2020, 2:05 PM · Restricted Project
pcc updated the diff for D86166: sanitizer_common: Use void* for madvise first argument on Solaris..

Add explanation to comment

Aug 18 2020, 2:05 PM · Restricted Project
pcc added a comment to D86166: sanitizer_common: Use void* for madvise first argument on Solaris..

@ro On D85870 you mentioned that the declaration has been changed in Solaris 11.4 to use void * which causes a build break on 11.4 due to the incompatible declaration. I checked illumos and it looks like their declaration still has caddr_t, although the comment above this declaration implies that that shouldn't matter because the system's declaration isn't visible. But what about older versions of Solaris? Presumably they still have a declaration with caddr_t so I imagine the build would break with an incompatible declaration error there. Or do we not care about older versions?

Aug 18 2020, 1:15 PM · Restricted Project
pcc added inline comments to D85870: sanitizer_common: Introduce internal_madvise and start using it..
Aug 18 2020, 1:11 PM · Restricted Project
pcc requested review of D86166: sanitizer_common: Use void* for madvise first argument on Solaris..
Aug 18 2020, 1:11 PM · Restricted Project

Aug 13 2020

pcc committed rGc201f2722585: hwasan: Emit the globals note even when globals are uninstrumented. (authored by pcc).
hwasan: Emit the globals note even when globals are uninstrumented.
Aug 13 2020, 4:34 PM
pcc closed D85871: hwasan: Emit the globals note even when globals are uninstrumented..
Aug 13 2020, 4:33 PM · Restricted Project
pcc added inline comments to D85871: hwasan: Emit the globals note even when globals are uninstrumented..
Aug 13 2020, 4:31 PM · Restricted Project
pcc added inline comments to D85870: sanitizer_common: Introduce internal_madvise and start using it..
Aug 13 2020, 4:14 PM · Restricted Project
pcc committed rG9f8c4039f202: sanitizer_common: Introduce internal_madvise and start using it. (authored by pcc).
sanitizer_common: Introduce internal_madvise and start using it.
Aug 13 2020, 1:10 PM
pcc closed D85870: sanitizer_common: Introduce internal_madvise and start using it..
Aug 13 2020, 1:10 PM · Restricted Project

Aug 12 2020

pcc requested review of D85871: hwasan: Emit the globals note even when globals are uninstrumented..
Aug 12 2020, 8:25 PM · Restricted Project
pcc requested review of D85870: sanitizer_common: Introduce internal_madvise and start using it..
Aug 12 2020, 7:56 PM · Restricted Project

Aug 6 2020

pcc added a comment to D76802: [InstrProfiling] Use !associated metadata for counters, data and values.
In D76802#2200926, @pcc wrote:

@davidxl does this look good to you? This feature is now gated on -counter-associated-metadata flag (I'd welcome suggestions for better name if you have some) because we require recent lld. We might be able to set that flag in the frontend when we know that the latest lld is being used in the future.

Can you find a better way of communicating this infomation than via an llvm::cl flag (e.g. use a function attribute)? The flag won't be compatible with LTO.

Do I understand your suggestion correctly that we would set function attribute when -fprofile-*-generate -fuse-lld is used that would enable the use of metadata in the backend?

Aug 6 2020, 2:37 PM · Restricted Project, Restricted Project
pcc added a comment to D76802: [InstrProfiling] Use !associated metadata for counters, data and values.

@davidxl does this look good to you? This feature is now gated on -counter-associated-metadata flag (I'd welcome suggestions for better name if you have some) because we require recent lld. We might be able to set that flag in the frontend when we know that the latest lld is being used in the future.

Aug 6 2020, 1:05 PM · Restricted Project, Restricted Project

Aug 5 2020

pcc accepted D72904: [ELF] Allow SHF_LINK_ORDER sections to have sh_link=0.

LGTM

Aug 5 2020, 4:05 PM · Restricted Project

Aug 3 2020

pcc added a comment to D67388: Add a feature to dump dependency graph..

I think this is actually a different feature to D82437?

Aug 3 2020, 4:28 PM · Restricted Project
pcc accepted D72899: [MC] Set sh_link to 0 if the associated symbol is undefined.

LGTM

Aug 3 2020, 1:23 PM · Restricted Project

Jul 24 2020

pcc added a comment to D84574: [lld-macho] Fix segment filesize calculation.

I think you can use wc -c. See e.g. clang/test/Modules/rebuild.m.

Jul 24 2020, 6:39 PM · Restricted Project
pcc accepted D82397: [scudo][standalone] mallopt runtime configuration options.

A possible concern was that this could be constraining future development by exposing implementation details. But I think that as long as we are free to change how these options are interpreted, or start ignoring them entirely, this is probably fine.

Jul 24 2020, 11:30 AM · Restricted Project
pcc accepted D83993: [scudo][standalone] Change the release loop for efficiency purposes.

LGTM

Jul 24 2020, 10:27 AM · Restricted Project

Jul 23 2020

pcc added a comment to D82397: [scudo][standalone] mallopt runtime configuration options.

Where does the configuration need to live? If it just needs to be a build-time configuration, that may be simpler than exposing new mallopt options.

Jul 23 2020, 4:44 PM · Restricted Project
pcc added inline comments to D83993: [scudo][standalone] Change the release loop for efficiency purposes.
Jul 23 2020, 4:33 PM · Restricted Project
pcc committed rGb83417aa7e26: scudo: Interleave odd and even tags for adjacent blocks. (authored by pcc).
scudo: Interleave odd and even tags for adjacent blocks.
Jul 23 2020, 3:10 PM
pcc closed D84361: scudo: Interleave odd and even tags for adjacent blocks..
Jul 23 2020, 3:09 PM · Restricted Project
pcc added a comment to D84414: [RISCV] Support Shadow Call Stack.

Any callee-saved register can be used.

Jul 23 2020, 12:48 PM · Restricted Project, Restricted Project
pcc added inline comments to D84414: [RISCV] Support Shadow Call Stack.
Jul 23 2020, 12:44 PM · Restricted Project, Restricted Project
pcc committed rG9b2164063f77: scudo: Remove some boilerplate from the combined allocator tests. NFCI. (authored by pcc).
scudo: Remove some boilerplate from the combined allocator tests. NFCI.
Jul 23 2020, 12:22 PM
pcc closed D84454: scudo: Remove some boilerplate from the combined allocator tests. NFCI..
Jul 23 2020, 12:22 PM · Restricted Project
pcc added inline comments to D84361: scudo: Interleave odd and even tags for adjacent blocks..
Jul 23 2020, 12:07 PM · Restricted Project
pcc updated the diff for D84361: scudo: Interleave odd and even tags for adjacent blocks..

Rebase

Jul 23 2020, 12:06 PM · Restricted Project
Herald added a project to D84454: scudo: Remove some boilerplate from the combined allocator tests. NFCI.: Restricted Project.
Jul 23 2020, 12:06 PM · Restricted Project

Jul 22 2020

pcc updated the diff for D84361: scudo: Interleave odd and even tags for adjacent blocks..

Add a tuning setting

Jul 22 2020, 5:46 PM · Restricted Project
Herald added a project to D84361: scudo: Interleave odd and even tags for adjacent blocks.: Restricted Project.
Jul 22 2020, 1:57 PM · Restricted Project

Jul 21 2020

pcc added a comment to D72904: [ELF] Allow SHF_LINK_ORDER sections to have sh_link=0.

See also @jhenderson's latest reply to the generic-abi thread "SHF_LINK_ORDER's original semantics make upgrade difficult"

# input.o:
<table header> [common]
- DW_TAG_compile_unit [common]
-- DW_TAG_variable [.data.foo]
-- DW_TAG_namespace [common]
--- DW_TAG_subprogram [.text.bar]
--- DW_TAG_variable [.data.baz]
<table footer> [common]

@pcc I sent the patches since you expressed a preference on more work on SHF_LINK_ORDER. Though, @jhenderson's needs (and my header/footer argument in that thread) make me think more whether we should continue patching SHF_LINK_ORDER or start pursuing another section flag.

Without metadata sections's override, SHF_LINK_ORDER will have very few use cases. The problems still exist but we probably don't really need to address them.

Jul 21 2020, 12:53 PM · Restricted Project
pcc added inline comments to D84001: [ELF] Allow mixed SHF_LINK_ORDER & non-SHF_LINK_ORDER sections and sort within InputSectionDescription.
Jul 21 2020, 12:35 PM · Restricted Project
pcc added a comment to D72899: [MC] Set sh_link to 0 if the associated symbol is undefined.

Doesn't this require a change to the parser to accept 0 in place of the linked symbol?

Jul 21 2020, 12:10 PM · Restricted Project

Jul 16 2020

pcc added inline comments to D83603: [lld-macho] Support __dso_handle for C++.
Jul 16 2020, 4:16 PM · Restricted Project

Jul 15 2020

pcc added inline comments to D83603: [lld-macho] Support __dso_handle for C++.
Jul 15 2020, 12:14 AM · Restricted Project

Jun 22 2020

pcc committed rGbd7defeb9409: llvm-nm: Implement --special-syms. (authored by pcc).
llvm-nm: Implement --special-syms.
Jun 22 2020, 1:27 PM
pcc closed D82251: llvm-nm: Implement --special-syms..
Jun 22 2020, 1:27 PM · Restricted Project
pcc added a comment to D82251: llvm-nm: Implement --special-syms..

Seems reasonable, but the llvm-nm documentation needs updating (see llvm/docs/CommandGuide/llvm-nm.rst).

It may also be worth release-noting the change in behaviour too, since it will mean current ARM users who use llvm-nm will see their mapping symbols disappear from the output, if they aren't already using --special-syms.

Jun 22 2020, 1:26 PM · Restricted Project

Jun 19 2020

pcc created D82251: llvm-nm: Implement --special-syms..
Jun 19 2020, 7:32 PM · Restricted Project

Jun 15 2020

pcc added a comment to D81801: Remove KillTheDoctor.

Win32 has an API for disabling error reporting which is already implemented in sys::DisableSystemDialogsOnCrash(), gtest and relevant test cases such as compiler-rt/test/asan/TestCases/ill.cpp.

Jun 15 2020, 9:13 AM · Restricted Project, Restricted Project

Jun 9 2020

pcc accepted D80599: [HWASan] Add sizeof(global) in report even if symbols missing..

LGTM

Jun 9 2020, 11:32 AM · Restricted Project, Restricted Project

Jun 8 2020

pcc added inline comments to D81410: [ELF][AArch64] Correct relocation codes for R_<CLS>_PLT32.
Jun 8 2020, 11:02 AM · Restricted Project

Jun 5 2020

pcc added inline comments to D77647: [ELF][AArch64] Add R_AARCH64_PLT32 relocation type..
Jun 5 2020, 6:59 PM · Restricted Project
pcc added inline comments to D77647: [ELF][AArch64] Add R_AARCH64_PLT32 relocation type..
Jun 5 2020, 3:10 PM · Restricted Project
pcc added inline comments to D76665: [asan] Stop instrumenting user-defined ELF sections.
Jun 5 2020, 12:22 PM · Restricted Project, Restricted Project

Jun 3 2020

pcc added a comment to D72904: [ELF] Allow SHF_LINK_ORDER sections to have sh_link=0.

Should we drop this and just let users set sh_link=self if they want these semantics?

Jun 3 2020, 11:32 AM · Restricted Project

Jun 2 2020

pcc added a comment to D80186: [Inliner] Update !associated metadata during inlining.
In D80186#2067298, @pcc wrote:

Yeah. Thinking about it more, you may consider a different !associated scheme for the __prof*_ globals.

  • __profc_* and __profn_* are associated with a dummy global (to allow the sections to be GC'd).
  • __profd_* is associated with the corresponding __profc_* section.

Now no special rules are required for inlining. __profc_* is kept alive via the references in the functions, __profd_ is kept alive via !associated and __profn_* is kept alive by direct reference.

I tried that, but now we get an error ld.lld: error: /tmp/instrprof-gc-sections-5f007f.o:(__llvm_prf_cnts): sh_link points to discarded section /tmp/instrprof-gc-sections-5f007f.o:(__llvm_prf_dummy) because the dummy global was discarded which creates a broken sh_link.

Jun 2 2020, 10:25 AM · Restricted Project

Jun 1 2020

pcc added a comment to D80186: [Inliner] Update !associated metadata during inlining.

Yeah. Thinking about it more, you may consider a different !associated scheme for the __prof*_ globals.

Jun 1 2020, 2:05 PM · Restricted Project
pcc updated subscribers of D80186: [Inliner] Update !associated metadata during inlining.

In this case you might consider replacing the global reference with null and implementing my proposal in https://bugs.llvm.org/show_bug.cgi?id=41734#c2 to make the section SHF_LINK_ORDER with a zero-length .init_array section.

Jun 1 2020, 12:59 PM · Restricted Project
pcc added inline comments to D76665: [asan] Stop instrumenting user-defined ELF sections.
Jun 1 2020, 10:45 AM · Restricted Project, Restricted Project

May 28 2020

pcc added inline comments to D80599: [HWASan] Add sizeof(global) in report even if symbols missing..
May 28 2020, 1:13 PM · Restricted Project, Restricted Project
pcc added inline comments to D80599: [HWASan] Add sizeof(global) in report even if symbols missing..
May 28 2020, 11:33 AM · Restricted Project, Restricted Project

May 27 2020

pcc added a comment to D80599: [HWASan] Add sizeof(global) in report even if symbols missing..

And instead of returning (global_begin, global_end) you could return something like an ArrayRef<hwasan_global> (I don't think we have ArrayRef in compiler-rt, but you could add one, it's pretty simple). Now the client code just looks like

for (hwasan_global &g : HwasanGlobalsFor(phdr, ...)) {
 ...
}
May 27 2020, 6:34 PM · Restricted Project, Restricted Project
pcc added a comment to D80599: [HWASan] Add sizeof(global) in report even if symbols missing..
In D80599#2056315, @pcc wrote:

Instead of adding these callbacks would it be simpler to have a function that takes the pointer to phdrs and returns (global_begin, global_end) (both 0 if not present)?

That would require duplicating the global iteration logic across the reporting and initialisation paths, which I was trying to avoid. Having a callback that recieves a single global is easier for my brain, but please let me know if you'd prefer it the other way around.

May 27 2020, 6:34 PM · Restricted Project, Restricted Project
pcc accepted D80647: [Driver] Support -fsanitize=shadow-call-stack on aarch64_be.

LGTM

May 27 2020, 10:50 AM · Restricted Project

May 26 2020

pcc added a comment to D80599: [HWASan] Add sizeof(global) in report even if symbols missing..

Instead of adding these callbacks would it be simpler to have a function that takes the pointer to phdrs and returns (global_begin, global_end) (both 0 if not present)?

May 26 2020, 6:33 PM · Restricted Project, Restricted Project
pcc added inline comments to D80591: Patch up pthread issues with GN build.
May 26 2020, 5:28 PM · Restricted Project

May 14 2020

pcc committed rGd2a26ad0dc2b: hwasan: Collect ring buffer statistics and include in dev note. (authored by pcc).
hwasan: Collect ring buffer statistics and include in dev note.
May 14 2020, 10:17 AM
pcc closed D79913: hwasan: Collect ring buffer statistics and include in dev note..
May 14 2020, 10:17 AM · Restricted Project
pcc accepted D79919: [Driver] Pass -plugin-opt=O2 for -Os -Oz and -plugin-opt=O1 for -Og.

LGTM

May 14 2020, 10:16 AM · Restricted Project

May 13 2020

pcc added a comment to D79818: [lld] Support size levels with (Thin)LTO.

@mehdi_amini @pcc @tejohnson

I just saw another issue saying that clang -Os -flto=thin a.c does not work https://bugs.llvm.org/show_bug.cgi?id=45913 (+ @manojgupta)
I marked it as yet another duplicate of PR42445

For -Os, clang driver passes -plugin-opt=Os (https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/CommonArgs.cpp#L402) but neither LLVMgold.so nor LLD recognizes -plugin-opt=Os.
-Oz is similar. What is the concrete suggestion here? For quick reference, the -plugin-opt=O logic was added by rL256146.

The issue form my perspective is the inconsistency. Today, lld accepts -plugin-opt=O<number> but it doesn't accept -plugin-opt=O<letter>, but Clang automatically translates -O<anything> to -plugin-opt=O<anything> which results in a failure when your try to use -Os, -Oz or -Og with (Thin)LTO.

May 13 2020, 4:57 PM · Restricted Project
pcc added a comment to D79913: hwasan: Collect ring buffer statistics and include in dev note..

Not sure if there's a good way to test this @eugenis?

May 13 2020, 4:57 PM · Restricted Project
pcc created D79913: hwasan: Collect ring buffer statistics and include in dev note..
May 13 2020, 4:57 PM · Restricted Project

May 12 2020

pcc added a comment to D79822: [AArch64] Emit CFI instruction for updating x18 when using ShadowCallStack with exception unwinding.

It is unclear to me whether removing the nounwind condition is necessary. The wording in the langref talks about "asynchronous exceptions" but only provides semantics for "exception handling schemes that are recognized by LLVM to handle asynchronous exceptions, such as SEH". Since we don't support anything like that on non-Windows. I don't believe that we need to support throwing exceptions past such functions on DWARF platforms, and the unwind info can only be used for the purpose of creating a stack trace.

May 12 2020, 5:15 PM · Restricted Project

May 6 2020

pcc accepted D79522: Allow -fsanitize-minimal-runtime with memtag sanitizer..

LGTM

May 6 2020, 4:30 PM · Restricted Project

May 1 2020

pcc committed rG8fac07a12adc: scudo: Exclude previous tag when retagging freed memory. (authored by pcc).
scudo: Exclude previous tag when retagging freed memory.
May 1 2020, 5:21 PM
pcc closed D79216: scudo: Exclude previous tag when retagging freed memory..
May 1 2020, 5:21 PM · Restricted Project

Apr 30 2020

pcc added a comment to D79153: [lld-macho] Avoid unnecessary preprocessing of relocations.

The architecture may need to be different here IMHO because of subsections. Don't forget that you need to map relocations onto subsections in order to implement gc-sections, and depending on the number of subsections you have per section, that could get expensive without an intermediate data structure. On top of that you'd still need the O(M log N) at output time. To me it seemed better to pay the O(M log N) up front once and avoid the cost at gc-sections time.

Apr 30 2020, 5:11 PM · Restricted Project
pcc created D79216: scudo: Exclude previous tag when retagging freed memory..
Apr 30 2020, 5:11 PM · Restricted Project