Re: [Factor-talk] Any way of making sense of what's in the boot image?
Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0CONSTANT: rt-entry-point 1CONSTANT: rt-entry-point-pic 2CONSTANT: rt-entry-point-pic-tail 3CONSTANT: rt-here 4CONSTANT: rt-this 5CONSTANT: rt-literal 6CONSTANT: rt-untagged 7CONSTANT: rt-megamorphic-cache-hits 8CONSTANT: rt-vm 9CONSTANT: rt-cards-offset 10CONSTANT: rt-decks-offset 11CONSTANT: rt-exception-handler 12CONSTANT: rt-dlsym-toc 13CONSTANT: rt-inline-cache-miss 14CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Thanks. Mike > Date: Thu, 9 Aug 2012 06:26:54 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett wrote: > > Hi Joe -- > > > > Thank you so much for your guidance. I'm assuming that it is the > > basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, > > stage1.factor and syntax.factor that you are referring to? > > > > One question just to help me get oriented before I go into heavy > > head-twisting mode. I notice that all these files have significant numbers > > of pre-existing vocabularies that they use. If this is what is used to > > generate the early stage1 bootstrapping stuff, then am I correct to assume > > that this is done from some version of factor where all this stuff has built > > already from scratch (that would be the implication, if all these files are > > able to use those vocabularies)? Or is there some other mechanism at work > > here that I should know about, and if so, is it written up anywhere that you > > know about. > > > > I have just read Slava's January 2010 post on the bootstrapping mechanism, > > so I understand the mechanism a bit better now, but am still thinking there > > has to be some Factor system somewhere that was built without a bootstrap > > image in order to have the vocabularies available that are used to generate > > the bootstrapping. Is there anything anywhere documenting that aspect of > > the picture. The reason I ask is that I would like to get a sense of how > > extensive that core fundamental set of vocabularies is that is needed to > > process the primitives and stage1 factor files. > > > > Here's the USING statement for primitives.factor: > > > > USING: alien alien.strings arrays byte-arrays generic hashtables > > hashtables.private io io.encodings.ascii kernel math > > math.private math.order namespaces make parser sequences strings > > vectors words quotations assocs layouts classes classes.private > > classes.builtin classes.singleton classes.tuple > > classes.tuple.private kernel.private vocabs vocabs.loader > > source-files definitions slots classes.union > > classes.intersection classes.predicate compiler.units > > bootstrap.image.private io.files accessors combinators ; > > IN: bootstrap.primitives > > > > It's got a lot of stuff there. Is a lot of this built in the C++ code that > > constitutes the VM? Or is some fundamental processing capability put into > > place that allows the processing of factor files to build these > > vocabularies? And if so, is the factor source used also included in the > > downloaded platform? Or was this a special primordial code base that was > > used once and never really needed again? > > Although core/bootstrap/primitives.factor is in core/, it's not > actually loaded as-is into the boot image; it's really a script > designed to run as part of `make-image` in the host image. All of > those modules are loaded and run in the host image. While there of > course had to have been a primordial Factor that could boot itself, I > think it would be too different now to resemble current Factor. > Factor's bootstrapping loop evolved somewhat organically. > > You can tell whether a word is a C++ primitive by `see`ing it in the > listener. Primitive words show up as `PRIMITIVE:` when prettyprinted. > > At a high level, `make-image` has two stages: First, it executes > `core/bootstrap/stage1.factor`, which runs 'bootstrap/syntax.factor` > to transfer the basic syntax from the host image to the boot image, > `bootstrap/primitives.factor` to set up primitive words corresponding > to VM primitives, and a CPU-specific `basis/cpu/*/bootstrap.factor` > script to assemble "sub-primitives" which are blobs of assembly >
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Those look like VM constants. A quick grep yields where an enum is defined in a header file that has comments about their purposes: $ find -name \*.hpp | xargs grep -l "RT_DLSYM" ./vm/instruction_operands.hpp Regards, --Alex Vondrak From: Michael Clagett [mclag...@hotmail.com] Sent: Monday, August 13, 2012 8:52 AM To: Factor-Talk Subject: [MARKETING] Re: [Factor-talk] Any way of making sense of what's in the boot image? Here's an obscure question that is of interest to me in my current quest, but probably not to anyone else. So if there is a better forum for me to ask such things, I would love to be instructed; until I hear otherwise, however, I will continue to use this list. Is there any place where I can penetrate the meaning of the following constants: CONSTANT: rt-dlsym 0 CONSTANT: rt-entry-point 1 CONSTANT: rt-entry-point-pic 2 CONSTANT: rt-entry-point-pic-tail 3 CONSTANT: rt-here 4 CONSTANT: rt-this 5 CONSTANT: rt-literal 6 CONSTANT: rt-untagged 7 CONSTANT: rt-megamorphic-cache-hits 8 CONSTANT: rt-vm 9 CONSTANT: rt-cards-offset 10 CONSTANT: rt-decks-offset 11 CONSTANT: rt-exception-handler 12 CONSTANT: rt-dlsym-toc 13 CONSTANT: rt-inline-cache-miss 14 CONSTANT: rt-safepoint 15 So far I've only encountered rt-here and I've only seen it encoded into a relocation entry and not really used anywhere yet. But this strikes me as the kind of thing it would be useful to know as I am slogging through this stuff. Not a hugely pressing question, as I'm sure I'll muddle through it. But if anyone has a moment to illuminate, it would be nice. Thanks. Mike > Date: Thu, 9 Aug 2012 06:26:54 -0700 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Wed, Aug 8, 2012 at 9:56 PM, Michael Clagett wrote: > > Hi Joe -- > > > > Thank you so much for your guidance. I'm assuming that it is the > > basis\bootstrap\image\image.factor and the core\bootstrap\primitives.factor, > > stage1.factor and syntax.factor that you are referring to? > > > > One question just to help me get oriented before I go into heavy > > head-twisting mode. I notice that all these files have significant numbers > > of pre-existing vocabularies that they use. If this is what is used to > > generate the early stage1 bootstrapping stuff, then am I correct to assume > > that this is done from some version of factor where all this stuff has built > > already from scratch (that would be the implication, if all these files are > > able to use those vocabularies)? Or is there some other mechanism at work > > here that I should know about, and if so, is it written up anywhere that you > > know about. > > > > I have just read Slava's January 2010 post on the bootstrapping mechanism, > > so I understand the mechanism a bit better now, but am still thinking there > > has to be some Factor system somewhere that was built without a bootstrap > > image in order to have the vocabularies available that are used to generate > > the bootstrapping. Is there anything anywhere documenting that aspect of > > the picture. The reason I ask is that I would like to get a sense of how > > extensive that core fundamental set of vocabularies is that is needed to > > process the primitives and stage1 factor files. > > > > Here's the USING statement for primitives.factor: > > > > USING: alien alien.strings arrays byte-arrays generic hashtables > > hashtables.private io io.encodings.ascii kernel math > > math.private math.order namespaces make parser sequences strings > > vectors words quotations assocs layouts classes classes.private > > classes.builtin classes.singleton classes.tuple > > classes.tuple.private kernel.private vocabs vocabs.loader > > source-files definitions slots classes.union > > classes.intersection classes.predicate compiler.units > > bootstrap.image.private io.files accessors combinators ; > > IN: bootstrap.primitives > > > > It's got a lot of stuff there. Is a lot of this built in the C++ code that > > constitutes the VM? Or is some fundamental processing capability put into > > place that allows the processing of factor files to build these > > vocabularies? And if so, is the factor source used also included in the > > downloaded platform? Or was this a special primordial code base that was > > used once and never really needed again? > > Although core/bootstrap/primitives.factor is in core/, it's not > actually loaded as-is into the boot image; it's really a script > designed to run as part of `make-image` in the host image. All of > those modules are loaded and run in the host image. While there of > course had to have been a primordial Factor that could boot itself, I > think it would be too different now to resemble current Factor. > Factor's bootstrapping loop evolved somewhat organically. > > You can tell whether a word is a C++ primitive by `see`ing it in the > listener. Primitive words sh
Re: [Factor-talk] Any way of making sense of what's in the boot image?
On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett wrote: > Here's an obscure question that is of interest to me in my current quest, > but probably not to anyone else. So if there is a better forum for me to > ask such things, I would love to be instructed; until I hear otherwise, > however, I will continue to use this list. > > Is there any place where I can penetrate the meaning of the following > constants: > > CONSTANT: rt-dlsym 0 > CONSTANT: rt-entry-point 1 > CONSTANT: rt-entry-point-pic 2 > CONSTANT: rt-entry-point-pic-tail 3 > CONSTANT: rt-here 4 > CONSTANT: rt-this 5 > CONSTANT: rt-literal 6 > CONSTANT: rt-untagged 7 > CONSTANT: rt-megamorphic-cache-hits 8 > CONSTANT: rt-vm 9 > CONSTANT: rt-cards-offset 10 > CONSTANT: rt-decks-offset 11 > CONSTANT: rt-exception-handler 12 > CONSTANT: rt-dlsym-toc 13 > CONSTANT: rt-inline-cache-miss 14 > CONSTANT: rt-safepoint 15 > > So far I've only encountered rt-here and I've only seen it encoded into a > relocation entry and not really used anywhere yet. But this strikes me as > the kind of thing it would be useful to know as I am slogging through this > stuff. > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > anyone has a moment to illuminate, it would be nice. Those are relocation record types. When the compiler generates code for a word, it also needs to generate relocation entries every time it references another word in a jump or call statement, much like a native C compiler needs to do for symbols in other modules. The VM uses these relocation entries to update the operands of jump and call instructions when code is written to the code heap, when the code heap is compacted, or if code is moved in memory for any reason. The different rt-* constants are used to describe what kind of object a relocation refers to, such as a foreign function in a DLL (dlsym), a word entry point (entry-point-*), the current address (here), etc. -Joe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Thank you, Joe, for the quick response. It was actually the information in the "such as" clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), the current address (here), etc. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Is this you? http://www.clarkprosecutor.org/html/death/US/clagett651.htm On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett wrote: > Thank you, Joe, for the quick response. It was actually the information in > the "such as" clause of your last sentence that I was looking for. I don't > mean for you to take the time out to document the meaning of these different > constants, but if it is documented somewhere other than in the creators' > heads, I would love to be directed to it. Not a big deal, because I'm sure > that when I get to seeing them used in the boot-image initialization code, > all will become clear. Still, it might help me better understand what's > being done at the make-image level to know. >> Date: Mon, 13 Aug 2012 12:21:52 -0400 > >> From: arc...@gmail.com >> To: factor-talk@lists.sourceforge.net >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot >> image? >> >> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett >> wrote: >> > Here's an obscure question that is of interest to me in my current >> > quest, >> > but probably not to anyone else. So if there is a better forum for me to >> > ask such things, I would love to be instructed; until I hear otherwise, >> > however, I will continue to use this list. >> > >> > Is there any place where I can penetrate the meaning of the following >> > constants: >> > >> > CONSTANT: rt-dlsym 0 >> > CONSTANT: rt-entry-point 1 >> > CONSTANT: rt-entry-point-pic 2 >> > CONSTANT: rt-entry-point-pic-tail 3 >> > CONSTANT: rt-here 4 >> > CONSTANT: rt-this 5 >> > CONSTANT: rt-literal 6 >> > CONSTANT: rt-untagged 7 >> > CONSTANT: rt-megamorphic-cache-hits 8 >> > CONSTANT: rt-vm 9 >> > CONSTANT: rt-cards-offset 10 >> > CONSTANT: rt-decks-offset 11 >> > CONSTANT: rt-exception-handler 12 >> > CONSTANT: rt-dlsym-toc 13 >> > CONSTANT: rt-inline-cache-miss 14 >> > CONSTANT: rt-safepoint 15 >> > >> > So far I've only encountered rt-here and I've only seen it encoded into >> > a >> > relocation entry and not really used anywhere yet. But this strikes me >> > as >> > the kind of thing it would be useful to know as I am slogging through >> > this >> > stuff. >> > >> > Not a hugely pressing question, as I'm sure I'll muddle through it. But >> > if >> > anyone has a moment to illuminate, it would be nice. >> >> Those are relocation record types. When the compiler generates code >> for a word, it also needs to generate relocation entries every time it >> references another word in a jump or call statement, much like a >> native C compiler needs to do for symbols in other modules. >> The VM uses these relocation entries to update the operands of jump >> and call instructions when code is written to the code heap, when the >> code heap is compacted, or if code is moved in memory for any reason. >> The different rt-* constants are used to describe what kind of object >> a relocation refers to, such as a foreign function in a DLL (dlsym), a >> word entry point (entry-point-*), the current address (here), etc. >> >> -Joe >> >> >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ___ >> Factor-talk mailing list >> Factor-talk@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
Re: [Factor-talk] Any way of making sense of what's in the boot image?
yes. I've come back to haunt y'all. > Date: Mon, 13 Aug 2012 09:50:04 -0700 > From: doug.cole...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > Is this you? > > http://www.clarkprosecutor.org/html/death/US/clagett651.htm > > On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett wrote: > > Thank you, Joe, for the quick response. It was actually the information in > > the "such as" clause of your last sentence that I was looking for. I don't > > mean for you to take the time out to document the meaning of these different > > constants, but if it is documented somewhere other than in the creators' > > heads, I would love to be directed to it. Not a big deal, because I'm sure > > that when I get to seeing them used in the boot-image initialization code, > > all will become clear. Still, it might help me better understand what's > > being done at the make-image level to know. > >> Date: Mon, 13 Aug 2012 12:21:52 -0400 > > > >> From: arc...@gmail.com > >> To: factor-talk@lists.sourceforge.net > >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > >> image? > >> > >> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > >> wrote: > >> > Here's an obscure question that is of interest to me in my current > >> > quest, > >> > but probably not to anyone else. So if there is a better forum for me to > >> > ask such things, I would love to be instructed; until I hear otherwise, > >> > however, I will continue to use this list. > >> > > >> > Is there any place where I can penetrate the meaning of the following > >> > constants: > >> > > >> > CONSTANT: rt-dlsym 0 > >> > CONSTANT: rt-entry-point 1 > >> > CONSTANT: rt-entry-point-pic 2 > >> > CONSTANT: rt-entry-point-pic-tail 3 > >> > CONSTANT: rt-here 4 > >> > CONSTANT: rt-this 5 > >> > CONSTANT: rt-literal 6 > >> > CONSTANT: rt-untagged 7 > >> > CONSTANT: rt-megamorphic-cache-hits 8 > >> > CONSTANT: rt-vm 9 > >> > CONSTANT: rt-cards-offset 10 > >> > CONSTANT: rt-decks-offset 11 > >> > CONSTANT: rt-exception-handler 12 > >> > CONSTANT: rt-dlsym-toc 13 > >> > CONSTANT: rt-inline-cache-miss 14 > >> > CONSTANT: rt-safepoint 15 > >> > > >> > So far I've only encountered rt-here and I've only seen it encoded into > >> > a > >> > relocation entry and not really used anywhere yet. But this strikes me > >> > as > >> > the kind of thing it would be useful to know as I am slogging through > >> > this > >> > stuff. > >> > > >> > Not a hugely pressing question, as I'm sure I'll muddle through it. But > >> > if > >> > anyone has a moment to illuminate, it would be nice. > >> > >> Those are relocation record types. When the compiler generates code > >> for a word, it also needs to generate relocation entries every time it > >> references another word in a jump or call statement, much like a > >> native C compiler needs to do for symbols in other modules. > >> The VM uses these relocation entries to update the operands of jump > >> and call instructions when code is written to the code heap, when the > >> code heap is compacted, or if code is moved in memory for any reason. > >> The different rt-* constants are used to describe what kind of object > >> a relocation refers to, such as a foreign function in a DLL (dlsym), a > >> word entry point (entry-point-*), the current address (here), etc. > >> > >> -Joe > >> > >> > >> -- > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. Discussions > >> will include endpoint security, mobile security and the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> ___ > >> Factor-talk mailing list > >> Factor-talk@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Factor-talk mailing list > > Factor-talk@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/factor-talk > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://ww
Re: [Factor-talk] Any way of making sense of what's in the boot image?
(So you had better be nice to me; I don't mess around.) > Date: Mon, 13 Aug 2012 09:50:04 -0700 > From: doug.cole...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > Is this you? > > http://www.clarkprosecutor.org/html/death/US/clagett651.htm > > On Mon, Aug 13, 2012 at 9:46 AM, Michael Clagett wrote: > > Thank you, Joe, for the quick response. It was actually the information in > > the "such as" clause of your last sentence that I was looking for. I don't > > mean for you to take the time out to document the meaning of these different > > constants, but if it is documented somewhere other than in the creators' > > heads, I would love to be directed to it. Not a big deal, because I'm sure > > that when I get to seeing them used in the boot-image initialization code, > > all will become clear. Still, it might help me better understand what's > > being done at the make-image level to know. > >> Date: Mon, 13 Aug 2012 12:21:52 -0400 > > > >> From: arc...@gmail.com > >> To: factor-talk@lists.sourceforge.net > >> Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > >> image? > >> > >> On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > >> wrote: > >> > Here's an obscure question that is of interest to me in my current > >> > quest, > >> > but probably not to anyone else. So if there is a better forum for me to > >> > ask such things, I would love to be instructed; until I hear otherwise, > >> > however, I will continue to use this list. > >> > > >> > Is there any place where I can penetrate the meaning of the following > >> > constants: > >> > > >> > CONSTANT: rt-dlsym 0 > >> > CONSTANT: rt-entry-point 1 > >> > CONSTANT: rt-entry-point-pic 2 > >> > CONSTANT: rt-entry-point-pic-tail 3 > >> > CONSTANT: rt-here 4 > >> > CONSTANT: rt-this 5 > >> > CONSTANT: rt-literal 6 > >> > CONSTANT: rt-untagged 7 > >> > CONSTANT: rt-megamorphic-cache-hits 8 > >> > CONSTANT: rt-vm 9 > >> > CONSTANT: rt-cards-offset 10 > >> > CONSTANT: rt-decks-offset 11 > >> > CONSTANT: rt-exception-handler 12 > >> > CONSTANT: rt-dlsym-toc 13 > >> > CONSTANT: rt-inline-cache-miss 14 > >> > CONSTANT: rt-safepoint 15 > >> > > >> > So far I've only encountered rt-here and I've only seen it encoded into > >> > a > >> > relocation entry and not really used anywhere yet. But this strikes me > >> > as > >> > the kind of thing it would be useful to know as I am slogging through > >> > this > >> > stuff. > >> > > >> > Not a hugely pressing question, as I'm sure I'll muddle through it. But > >> > if > >> > anyone has a moment to illuminate, it would be nice. > >> > >> Those are relocation record types. When the compiler generates code > >> for a word, it also needs to generate relocation entries every time it > >> references another word in a jump or call statement, much like a > >> native C compiler needs to do for symbols in other modules. > >> The VM uses these relocation entries to update the operands of jump > >> and call instructions when code is written to the code heap, when the > >> code heap is compacted, or if code is moved in memory for any reason. > >> The different rt-* constants are used to describe what kind of object > >> a relocation refers to, such as a foreign function in a DLL (dlsym), a > >> word entry point (entry-point-*), the current address (here), etc. > >> > >> -Joe > >> > >> > >> -- > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. Discussions > >> will include endpoint security, mobile security and the latest in malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> ___ > >> Factor-talk mailing list > >> Factor-talk@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/factor-talk > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Factor-talk mailing list > > Factor-talk@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/factor-talk > > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware >
Re: [Factor-talk] Any way of making sense of what's in the boot image?
Been looking at some of the x86 assembler code. Damn! All I can say is that I wish to hell I had had Factor when I wrote my own. Quite a bit different approach, but the clarity and succinctness is tantalizing. From: mclag...@hotmail.com To: factor-talk@lists.sourceforge.net Date: Mon, 13 Aug 2012 16:46:38 + Subject: Re: [Factor-talk] Any way of making sense of what's in the boot image? Thank you, Joe, for the quick response. It was actually the information in the "such as" clause of your last sentence that I was looking for. I don't mean for you to take the time out to document the meaning of these different constants, but if it is documented somewhere other than in the creators' heads, I would love to be directed to it. Not a big deal, because I'm sure that when I get to seeing them used in the boot-image initialization code, all will become clear. Still, it might help me better understand what's being done at the make-image level to know. > Date: Mon, 13 Aug 2012 12:21:52 -0400 > From: arc...@gmail.com > To: factor-talk@lists.sourceforge.net > Subject: Re: [Factor-talk] Any way of making sense of what's in the boot > image? > > On Mon, Aug 13, 2012 at 11:52 AM, Michael Clagett > wrote: > > Here's an obscure question that is of interest to me in my current quest, > > but probably not to anyone else. So if there is a better forum for me to > > ask such things, I would love to be instructed; until I hear otherwise, > > however, I will continue to use this list. > > > > Is there any place where I can penetrate the meaning of the following > > constants: > > > > CONSTANT: rt-dlsym 0 > > CONSTANT: rt-entry-point 1 > > CONSTANT: rt-entry-point-pic 2 > > CONSTANT: rt-entry-point-pic-tail 3 > > CONSTANT: rt-here 4 > > CONSTANT: rt-this 5 > > CONSTANT: rt-literal 6 > > CONSTANT: rt-untagged 7 > > CONSTANT: rt-megamorphic-cache-hits 8 > > CONSTANT: rt-vm 9 > > CONSTANT: rt-cards-offset 10 > > CONSTANT: rt-decks-offset 11 > > CONSTANT: rt-exception-handler 12 > > CONSTANT: rt-dlsym-toc 13 > > CONSTANT: rt-inline-cache-miss 14 > > CONSTANT: rt-safepoint 15 > > > > So far I've only encountered rt-here and I've only seen it encoded into a > > relocation entry and not really used anywhere yet. But this strikes me as > > the kind of thing it would be useful to know as I am slogging through this > > stuff. > > > > Not a hugely pressing question, as I'm sure I'll muddle through it. But if > > anyone has a moment to illuminate, it would be nice. > > Those are relocation record types. When the compiler generates code > for a word, it also needs to generate relocation entries every time it > references another word in a jump or call statement, much like a > native C compiler needs to do for symbols in other modules. > The VM uses these relocation entries to update the operands of jump > and call instructions when code is written to the code heap, when the > code heap is compacted, or if code is moved in memory for any reason. > The different rt-* constants are used to describe what kind of object > a relocation refers to, such as a foreign function in a DLL (dlsym), a > word entry point (entry-point-*), the current address (here), etc. > > -Joe > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/list
