[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] #401: Improved design of address object design
|
I could accept Boolean unknownLength and unknownOffsetFromParent, default false for both. I will write it this way and send a draft. I can always change this aspect of the design if the TC objects. Larry -----Original Message----- I think this alternative complicates the math for consumers, a boolean name unknownLength and unknownOffset would be better choices if there can't be a null value. The default value could be the length not equal to the default length
or offset (-1 would be good default). Then length and offset can take any value, negative or positive. Jim On 4/29/19 12:45 PM, Larry Golding (Myriad Consulting Inc) wrote: > As an alternative to allowing lengthand offsetFromParentto be negative,
> we could define a property growthDirection(or even just direction)
> values "positive"and "negative", default value "positive". If itâs
> "negative", then both offsetFromParentand lengthare interpreted as
> negative numbers. > > Iâm not 100% happy with that either â it would be too easy for an SDK
> consumer to add offsetFromParentto its parent address without noticing
> it should have reversed the sign. > > *From:*Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com> > *Sent:* Monday, April 29, 2019 10:25 AM > *To:* Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>;
> James Kupsch <kupsch@cs.wisc.edu>; Michael Fanning
> <Michael.Fanning@microsoft.com>; OASIS SARIF TC Discussion List
> <sarif@lists.oasis-open.org> > *Subject:* RE: [sarif] #401: Improved design of address object design > > Another question: What does a lengthof zero mean? Is it an âinsertion
> pointâ, a zero-length range preceding the location specified by
> offsetFromParent/absoluteAddress/relativeAddress? > > *From:*sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>
> <sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>> *On
> Behalf Of *Larry Golding (Myriad Consulting Inc) > *Sent:* Monday, April 29, 2019 10:18 AM > *To:* James Kupsch <kupsch@cs.wisc.edu <mailto:kupsch@cs.wisc.edu>>;
> Michael Fanning <Michael.Fanning@microsoft.com > <mailto:Michael.Fanning@microsoft.com>>; OASIS SARIF TC Discussion List
> <sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>> > *Subject:* RE: [sarif] #401: Improved design of address object design > > Sorry, I shouldnât have directed those questions only to Michael. It was
> just because he proposed the original redesign in #403. Of course I want
> to hear feedback from the entire TC. > > *From:*Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com
> <mailto:v-lgold@microsoft.com>> > *Sent:* Monday, April 29, 2019 10:16 AM > *To:* Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com
> <mailto:v-lgold@microsoft.com>>; James Kupsch <kupsch@cs.wisc.edu
> <mailto:kupsch@cs.wisc.edu>>; Michael Fanning
> <Michael.Fanning@microsoft.com <mailto:Michael.Fanning@microsoft.com>>;
> OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org
> <mailto:sarif@lists.oasis-open.org>> > *Subject:* RE: [sarif] #401: Improved design of address object design > > Another concern I have is around length. I want to be able to write that
> if an addressobject occurs within a physicalLocationobject thisObject,
> and if thisObject.lengthand thisObject.address.lengthare both present,
> then then *SHALL* be equal. > > As the spec stands, I canât write this because physicalLocation.lengthis
> non-negative. I can add words like this: > > If an addressobject occurs within a physicalLocationobject thisObject,
> and if thisObject.lengthand thisObject.address.lengthare both present,
> then then *SHALL* be equal. In that case, if thisObject.address.lengthis
> negative, then thisObject.lengthwill also be negative. In all other
> circumstances, lengthSHALL be non-negative. > > *Michael*, are you ok with that complication? > > Larry > > *From:*sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>
> <sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>> *On
> Behalf Of *Larry Golding (Myriad Consulting Inc) > *Sent:* Monday, April 29, 2019 10:08 AM > *To:* James Kupsch <kupsch@cs.wisc.edu <mailto:kupsch@cs.wisc.edu>>;
> Michael Fanning <Michael.Fanning@microsoft.com > <mailto:Michael.Fanning@microsoft.com>>; OASIS SARIF TC Discussion List
> <sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>> > *Subject:* RE: [sarif] #401: Improved design of address object design > > Jim, > > From an SDK standpoint we have a problem with negative values because
> without -1 as a sentinel value, we need to make the .NET type
> Nullable<int>instead of int. So far we have avoided nullables in the
> API. Our code generation doesnât currently support them, but it wouldnât
> be hard to add. > > *Michael*, could you weigh in on this? The .NET Framework Design
> Guidelines (Â8.8) say: > > *CONSIDER*using Nullable<T>to represent values that might not be present
> (/i.e./, optional values). > > ** > > â and a quick web search doesnât turn up recommendations to avoid them
> in this scenario. > > Iâd just be concerned that this is the only place we have nullables. Are
> there alternatives? > > In the meantime Iâll write the words for the rest of Jimâs feedback. > > Larry > > *From:*James Kupsch <kupsch@cs.wisc.edu <mailto:kupsch@cs.wisc.edu>> > *Sent:* Monday, April 29, 2019 8:40 AM > *To:* Michael Fanning <Michael.Fanning@microsoft.com > <mailto:Michael.Fanning@microsoft.com>>; Larry Golding (Myriad
> Consulting Inc) <v-lgold@microsoft.com <mailto:v-lgold@microsoft.com>>;
> OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org
> <mailto:sarif@lists.oasis-open.org>> > *Subject:* Re: [sarif] #401: Improved design of address object design > > For #2,I was thinking the "stack" kind would be the whole stack. Also
> having a "stackFrame" kind would also be useful as it also a defined
> memory region contained within the "stack" kind. > > JIm > > On 4/29/19 10:20 AM, Michael Fanning wrote: > > Right now, the effective address is absolute if unparented and relative
> to some other thing, if parented. > > If you chase to the root object, letâs say itâs a module, its effective
> address provides the ability to distinguish a childâs relative address
> vs. physical memory location. > > IOW, the childâs relative address is its offset + all offsets up to (but
> not including) the root object. If you add the effective address of the
> root object, you get the absolute memory address (if available). > > Make sense? What do you think? > > For #2 stack, is the kind a stack frame? > > For #3, I see the problem. Every address in a PLC has an associated
> region but the run.addresses cache does not provide this association.
> Let me have a word with Larry. > > *From:*sarif@lists.oasis-open.org <mailto:sarif@lists.oasis-open.org>
> <sarif@lists.oasis-open.org> <mailto:sarif@lists.oasis-open.org>
*On > Behalf Of *James Kupsch > *Sent:* Monday, April 29, 2019 8:06 AM > *To:* Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
> <mailto:v-lgold@microsoft.com>; OASIS SARIF TC Discussion List
> <sarif@lists.oasis-open.org> <mailto:sarif@lists.oasis-open.org> > *Subject:* Re: [sarif] #401: Improved design of address object design > > After reading the address section changes. I have a couple of comments: > > 1) I would think that a common use of address would be something on the
> stack. To facilitate this, the offsetFromParent should be allowed to be
> negative as the "bottom" of stack is most logical place to be offset
> from, and since some stacks grow from higher to lower memory addresses,
> the offset is negative. The use of -1 for unknown mechanism would have
> to be changed for this to work. > > 2) Add stack as a kind > > 3) There is a length in physical location, but not all addresses will
> appear in a physical location (probably just those without parentIndex)
> a length field would be useful. This allows the producers to specify
> the lengths of the parent addresses that are regions in memory, and for
> consumers to determine them. The length should be allowed to be negative
> to handle the stack case cleanly and to indicate that it grows towards
> decreasing values (if length is negative the regions is from (address -
> offset) to address. For instance if I have an address in a physical
> object, a question that I might want to know is does this address
> overflow a containing memory region. > > 4) effectiveAddress can be one of two types of addresses: a relative
> address to some logical memory/file region, and an absolute memory
> address. These concepts are independent, are both useful, and should be
> distinguishable from one another. Something like: > > *offsetFromParent* - offset from containing parent (same as existing) > *parentIndex* - direct container address region if there is one (same
> as existing) > *offsetFromLogicalAddressRegion* - offset from some base logical region
> of memory (like effectiveAddress) > *logicalAddressRegionIndex* - the base logical region of memory the
> above offset if relative to > *absoluteMemoryAddress* - absolute memory address of address (physical
> or virtual, be consistent). Optional, recommended to only be included
> on addresses without parentIndex. > > Right now the effectiveAddress is difficult to use as they can not be
> compared without first figuring out what they are relative to and it
> isn't clear if the effective address is relative to something or absolute. > > Jim > > On 4/28/19 2:25 PM, Larry Golding (Myriad Consulting Inc) wrote: > > I created and pushed a change draft for Issue #401 > <https://nam06.safelinks.protection.outlook.com/?url="">>,
> âImproved address object designâ. > >
https://nam06.safelinks.protection.outlook.com/?url="">
> <https://nam06.safelinks.protection.outlook.com/?url="">> > > The original design was ambiguous about what address.offset was based
> on: the parent object, or address.baseAddress? > > * We renamed offset to offsetFromParent to clear up that ambiguity. > * We removed baseAddress because once itâs clear that âoffsetâ is > based on the parent object, thereâs no need to duplicate the > information in the child object. > * We added some more kind values ("header", "table") and we (really > Michael) made the definitions of "section" and "segment" more > precise. We (this time, really me
😊) also added text acknowledging > that the meanings of these terms are OS-dependent, and recommending > that SARIF producers use the term most appropriate for the target OS. > * Finally, an innovation: we introduced a property effectiveAddress, > which, when not present, can in certain circumstances be calculated > by adding the offsets all the way up the ancestor chain. (The > precise algorithm is in the spec.) This has two benefits: > o It allows the consumer to see the final address without having > to walk all the way up the ancestor chain. This at first /seems/ > duplicative in the same way that baseAddress was (although even > if that were true, effectiveAddress saves the consumer more work > than baseAddress did because baseAddress duplicated information > in a /single/ address object rather than a whole chain of them). > *BUT!* Itâs not really duplicative, becauseâ > o The effectiveAddress property allows a consumer to see the final > address /even if some of the information required to calculate > it is missing from the ancestor addresses/. This allows you to > say, for example, âHere is the address of this entry in the > exception handler table; the table entry is a child of the > table, which is itself a child of some other thingâ â without > having to specify the address of the exception handler table if > you donât think thatâs relevant. > > This draft also includes a small amount of residual editorial feedback. > > As always, the provisional draft and its HTML version are up to date: > >
https://nam06.safelinks.protection.outlook.com/?url="">
> <https://nam06.safelinks.protection.outlook.com/?url="">> > >
https://nam06.safelinks.protection.outlook.com/?url="">
> <https://nam06.safelinks.protection.outlook.com/?url="">> > > *Please take a look.* We still plan to open the CSD 2 ballot on Monday. > > Thanks, > > Larry > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]