similar to: [MTE] Globals Tagging - Discussion

Hi David, Does the tagging of these hidden symbols only protect against RW > primitives without a similar ldg? If I knew the address of the hidden > symbol I could presumably use the same sequence, but I think I'm > stretching what memory tagging is supposed to protect against. I might be missing your point here - but don't forget that the local globals are always PC-relative

> I might be missing your point here - but don't forget that the local globals are always PC-relative direct loads/stores. I did forget! Thanks for clarifying, now I understand. On Fri, 18 Sep 2020 at 20:51, Evgenii Stepanov <eugenis at google.com> wrote: > > > > On Fri, Sep 18, 2020 at 12:18 PM Mitch Phillips via llvm-dev <llvm-dev at lists.llvm.org> wrote:

> > note: these bits are not really reserved for os or processor > specific use in ELF. in practice they are processor specific > so it will be STO_AARCH64_TAGGED. > Correct. note2: undefined symbol references will need correct marking > too if objects may get copy relocated into the main exe and > linkers should check if definitions match references. Yep - at this point I

Thanks for the update, Phillips. Yes, please add me, Stephen and Ana (CCed) to Phabricator reviews. Zhaoshi From: Mitch Phillips <mitchp at google.com> Sent: Tuesday, July 14, 2020 19:10 To: Zhaoshi Zheng <zhaoshiz at quicinc.com> Cc: llvm-dev at lists.llvm.org; Stephen Long <steplong at quicinc.com> Subject: [EXT] Re: [llvm-dev] [MTE] Tagging Globals Hi Zhaoshi, Currently

Hello, We're evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

Hi Jim, Thanks for reviewing the patch. I couldn't get rid of STLExtras.h, but other than that, I followed all the suggestions in your email. Please let me know if you notice anything else that needs fixing. On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Akira, > > This is looking good. Some specific comments on the details below. > >

Hi Akira, Just two very minor things that I missed the first time around. 1. The 'fixup" member of ELFRelocation entry should be "Fixup" instead. 2. Since we're always passing in a non-NULL fixup, that should probably be a reference, not a pointer. Good for commit with those tweaks. Thanks! -Jim On Mar 23, 2012, at 1:07 PM, Akira Hatanaka wrote: > Hi Jim, >

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

Not at this stage -- no. On Wed, Jul 15, 2020 at 3:23 PM Zhaoshi Zheng <zhaoshiz at quicinc.com> wrote: > Mitch, > > > > I forgot to ask: do you have any timeline on sharing it through > Phabricator? > > > > Thanks, > > Zhaoshi > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Zhaoshi > Zheng via llvm-dev

The ELF relocation record format is different for N64 which many Mips 64 ABIs use than for O64 which many if not all other target ABIs use. The question I have is whether to treat N64 as a valid generic variant or should it be treated as target specific? My contention is that it should be treated as an alternative generic format handled recognized and handled in the ELF class objects above the

Hi, Since the below is a little long, I put my question at the top: how do I troubleshoot awful exported resources performance in puppet and is there anything I can tweak to get it to run under 10 minutes in larger environments? I have a fairly modest environment (118 nodes, but prod will be at least twice as large). I''m trying to move my distributed nagios setup to one based on

Hi everyone, I believe the ABI for exception unwinding on a stack tagged with MTE needs to be clarified -- hopefully we can start the discussion here? (Please feel free to add people to the thread that you think would be interested). I'll outline some possible approaches that I think seem good below, I know Evgenii and Peter have done a lot of investigation in this area for HWASAN, so

So we have been busy implementing the compute engine lately but we have discovered a few issues with Compute Shaders. I hope you guys can answer some questions. 1st How do I determine the size of Compute Shaders/Kernel Local Memory ? In Pipeline shaders the size is included in the header but Compute Kernels don't have a header, so how do I determine how much local memory it uses? In case I

* Rahul Chaudhry via gnu-gabi: > The encoding used is a simple combination of delta-encoding and a > bitmap of offsets. The section consists of 64-bit entries: higher > 8-bits contain delta since last offset, and lower 56-bits contain a > bitmap for which words to apply the relocation to. This is best > described by showing the code for decoding the section: > > typedef

Hi Shankar, On Tue, Feb 12, 2013 at 10:46 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Author: shankare > Date: Tue Feb 12 12:46:53 2013 > New Revision: 174990 > > URL: http://llvm.org/viewvc/llvm-project?rev=174990&view=rev [...] > ELFDefinedAtom<ELFT> *createDefinedAtomAndAssignRelocations( > StringRef symbolName, StringRef

+llvm-dev Discussion here: https://sourceware.org/ml/gnu-gabi/2017-q2/msg00000.html On Tue, May 2, 2017 at 10:17 AM, Suprateeka R Hegde <hegdesmailbox at gmail.com> wrote: > On 02-May-2017 12:05 AM, Florian Weimer wrote: >> On 05/01/2017 08:28 PM, Suprateeka R Hegde wrote: >>> So the ratio shows ~96% is RELATIVE reloc. And only ~4% others. This is >>> not the

Hello Leslie, The errors coming from the gnu assembler are due to the file being assembled in Arm state, to get rid of the errors you'll either need to put a .thumb directive in the file, or pass -mthumb to the assembler via arm-linux-gnu-gcc -Wa,-mthumb (I think). I'm not able to explain what you are seeing in your print out as it doesn't quite match the map file. Looking at your

Hi, I'm trying to implement a 10-bit relocation that does not start at the beginning of a byte-boundary and I'm not entirely sure I understand the use by some targets of MCFixup.Offset and MCFixupKindInfo.TargetOffset. LLVM's documentation states that: MCFixup.Offset -"/// The byte index of start of the relocation inside the encoded instruction."