Vm-dev May 2020

vm-dev@lists.squeakfoundation.org

39 participants
130 discussions

Re: [Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Newspeak VMs do not open the Newspeak UI on Windows (#151)
by Gilad Bracha 31 May '20

31 May '20

Had not noticed this before (I had given up on the issue long ago, I'm afraid). Will try and revisit. Thanks. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/151#issuecomment-6…

1 0

Re: [Vm-dev] [Vm-beginners] Stability of the external plugin interface
by Eliot Miranda 31 May '20

31 May '20

Hi Philip, Hi All, > On May 24, 2020, at 2:37 PM, Philip Bernhart <philip.bernhart(a)posteo.de> wrote: > > Hi Eliot, > > Eliot Miranda <eliot.miranda(a)gmail.com> writes: > >> Hi Philip, >> >>> On Sat, May 23, 2020 at 9:27 AM Philip Bernhart <philip.bernhart(a)posteo.de> >>> wrote: >>> >>> Hello, >>> >>> I want to write an external plugin - I think, >>> for having a fast interface to a C library. >>> >>> How is that currently done? >> >> >> Either by writing a plugin or directly through the FFI. We can discuss how >> to make the choice between the two but I lean towards the FFI. > > Why is that? I see the case for calling external libraries in a more > general fashion FFI. I see why people don't want to have additional > plugins in the VM too, more stuff to maintain -> more bugs, also some > VM internal resource exhaustion issues associated with internal > plugins(?), etc. > I'm not asking for that, I'm talking about external plugins. > > I read a little bit the Swiki articles about FFI / Plugins and people > who wrote them generally seemed to lean toward plugins, when it comes to > a layer provided to the users of the functionality which is supposed > to be put into the plugin / library. And they seemed to be a little > bit faster than the FFI interface. > > So what are your reasons for prefering FFI over External Plugins? :-) here is an extract of a recent conversation with Marcel Taumael and others that started off-line. It states my reasons for preferring FFI over plugins. ———8<——— > On May 13, 2020, at 5:58 AM, Marcel Taeumel <marcel.taeumel(a)hpi.de> wrote: > > > Hi Nicolas, hi Eliot, hi Levente, hi Vanessa. > > What is your opinion about "SDL through FFI" as it is proposed as the big thing in the "minheadless" branch and heavily used in recent Pharo versions? > > I think that > - Yes, it is a good idea to reduce the need for platform-specific code. > - No, it is a terrible idea to let SDL (or any C) internals bleed in to the regular Squeak/Smalltalk image. > - Instead, we should design a simple "WindowPlugin" that can easily map to SDL in a cross-platform fashion. Such a plugin can be extended to provide debugging support in a domain-specific way. > - However, it should always remain possible to provide alternative backends to SDL (such as Qt or native OS libs) for experimentation or workarounds or bugfixes. Just like the "Project" abstraction in Squeak to keep MVC and Morphic and whatever around at the same time. > > Isn't that what the unix part is doing anyway? vm-display-X11, vm-display-Quartz ... I have just spent several months porting the 32-bit Qwaq/Teleplace/3DICC plug-ins to 64-bit in Terf, the Croquet-based business communication tool, first on macOS, second on Windows. It has been an enormously expensive and slow process. Part of the problem is that some plugins involve three languages, C in the Slang-generated wrapper, C++ in the generic Qwaq library and the boost support libs (queues, locking, synchronization, etc), and Objective-C. Part of the problem is using low-level debuggers for the static languages involved. It is incredibly slow and costly work. Ronie has had to implement a new rendering framework because (I think, Ronie can explain better than me), Apple is not interested in supporting OpenGL in 64-bits as the world transitions to graphics co-processing for rendering, and also because he can do a better job himself than being concerned strained by an aging API such as OpenGL. Apart from the fact that Ronie is a better programmer than I, Ronie’s productivity has been much higher. I was porting existing code, and he was writing new code. I was working with low-level code expressed as plugins. He had built a meta-programming facility in Smalltalk and generates an FFI binding and a backend composed of gpu-specific back end dlls in C++. Apart from security and packaging, plugins are a disaster: - having to generate the plugin wrapper means two focii for development, in Smalltalk and on the platform (Ronie’s approach has the same issue but not so bad because apart from building and debugging the gpu-specific dlls the focus is in Smalltalk, where it should be). - architecturally plug-ins force inefficiencies due to marshaling across the Smalltalk/platform boundary and force data copying (we have pinning now, so copying can and should be reduced, in using plugins or using the FFI, but the Qwaq plugins were written before pinning was available). - browsing the plugins cannot be done in a single IDE; there aren’t good IDEs on linux, MacOS and Windows don’t share a common IDE, so changing a plug-in API takes a lot of browsing effort - architecturally the plugin forces the definition of *three* APIs, the plugin API between Smalltalk and the plugin’s internals, and the common internal API between the marshaled Smalltalk objects in the Slang-generated C plugin wrapper and the platform-specific code, and finally between this common internal API and each platform’s facilities. In an FFI-based implementation there is at most one API per platform, and it is easier to use facilities such as pinning to ease passing Smalltalk objects to external code. Going forward, we will have a much more effective optimizer in Sista/Scorch and a much more flexible threaded FFI, along with an incremental global garbage collector. This should provide facilities that make it feasible to move more computation into Smalltalk. Within Smalltalk the facilities for creating platform-neutral APIs that internally map to platform-specific APIs accesses through the FFI are much better than the static language facilities provided by C/C++/Objective-C et al, and the programming experience is much easier because there is only one foreign API to deal with, not three. The rate of development is much much faster. If we stay with plugins we fall into the Python trap. The plugin legacy is hugely expensive and restrictive, and prevents us from evolving, both because there is substantial investment and performance in the plugins and because they are inherently more viscous (for the 3 API reasons above). For these reasons I think it would be a huge mistake to develop any new rendering framework or platform interface using plugins. The development should be in Smalltalk across the FFI. Once a facility has been developed then one could auto generate a sandboxed implementation which replaces an open and potentially insecure FFI interface with a black box plugin, but this would be a packaging option, and not the main development line. Further, we could perhaps develop a different style of security, building on the ideas of the SecurityPlugin. Perhaps we could parameterize the FFI so it will only allow certain functions to be called. Imagine for example an FFISecurityPlugin which is built statically that combines a list of names (the names of the foreign functions that the image is allowed to call), with the dlls the FFI is allowed to use (either the dlls themselves or their names). Attempts to use foreign functions or dlls outside the names in the predefined set, would be outlawed. So my experience, not just the recent experience with 3D ICC, but also many years with VisualWorks, and some before with BrouHaHa, leads me to push strongly for embracing the FFI and addressing security issues directly, without tying our hands and putting an albatross around our necks to weigh us down. Plugins emerged from the lack of an FFI, later a deficient FFI (slow, non-reentrant, no callbacks), and the need for security, at a time when graphics co-processing was very rare and not at all commodity technology. The world looks different now. We should evolve to match the new environment. I agree that security is very important. But I do not believe that security implies no FFI. I think we can have both security and the flexibility, development speed and architectural efficiency of an FFI-based implementation. ———8<——— > > > Thanks for your time, > Philip

10 24

VM Maker: VMMaker-dtl.416.mcz
by commits＠source.squeak.org 30 May '20

30 May '20

David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.416.mcz ==================== Summary ==================== Name: VMMaker-dtl.416 Author: dtl Time: 30 May 2020, 5:02:53.744 pm UUID: 3ac9deb8-7142-4269-96bd-a9455f13f32d Ancestors: VMMaker-dtl.415 Apply fix by K K Subbu for simulator initialization. allowAccessBeyondSP is initialized in Interpreter but not in InterpreterSimulator. When the simulator is started on Squeak32-3.8g-6548 image, this triggers an undefined reference in EshouldBoundAccessWithinStackFor:withFormat: =============== Diff against VMMaker-dtl.415 =============== Item was changed: ----- Method: InterpreterSimulator>>test (in category 'testing') ----- test transcript clear. byteCount := 0. quitBlock := [^ self]. + allowAccessBeyondSP := self useOldPrimitives. "some old images must disable stack bounds check" self internalizeIPandSP. self fetchNextBytecode. [true] whileTrue: [self dispatchOn: currentBytecode in: BytecodeTable. byteCount := byteCount + 1. byteCount \\ 10000 = 0 ifTrue: [self fullDisplay]]. self externalizeIPandSP. !

1 0

Re: [Vm-dev] [urgent] Spur sometimes produces unloadable, image segments
by Max Leske 30 May '20

30 May '20

Hi Dave, hi Eliot, Thank you for responding so quickly! > Hi Max, > > I'm not sure if it would help, but if there is a code snippet that > reproduces the failure, I can try running it on Squeak to see if it > gives any clues. The images have lots of code in them and there are a couple of Pharo specifics in there, so I'm pretty sure we'd run into issues trying that. But thanks for the offer. > > Dave > On Sat, May 30, 2020 at 07:00:29PM +0200, Max Leske wrote: > >> >> Hi everyone, >> >> I desperately need some help with image segments in spur (Pharo). After having tested close to 1000 image segments that were written with a spur VM I have ended up with a couple that can't be loaded. I can reproducibly generate them from our old segements (Squeak 4 VM). >> >> Without full confidence in the image segment code I can't upgrade and couldn't upgrade those few instances anyway. I would be very thankful if someone had the time to look into this quickly. >> >> I will try to debug it myself but it will probably take me a couple of hours (if not days) until I have succeeded in building a VM that I can debug. >> >> >> Cheers, >> Max > Hi Max, > >> On May 30, 2020, at 10:00 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi everyone, >> >> I desperately need some help with image segments in spur (Pharo). After having tested close to 1000 image segments that were written with a spur VM I have ended up with a couple that can't be loaded. I can reproducibly generate them from our old segements (Squeak 4 VM). >> >> Without full confidence in the image segment code I can't upgrade and couldn't upgrade those few instances anyway. I would be very thankful if someone had the time to look into this quickly. >> >> I will try to debug it myself but it will probably take me a couple of hours (if not days) until I have succeeded in building a VM that I can debug. > > The only way this can be debugged realistically is to be able to simulate the reproducible case in the VMMaker simulator. Is there any possibility of this working? How big is the image in the reproducible case? What facilities does it use (I’m guessing external imaging which as yet can’t be simulated). If this can be made to occur headless and is hundreds of megabytes or less not gigabytes then we have a good chance of reproducing it in the simulator. > I don't know how big the image would be because we never save it. When we start the image, however, it's currently 54 MB. I currently don't know the exact size but it's very likely somwhere between 100 and 200 MB. The images run headless already when this happens. I'm not sure what you mean by external imaging and facilities. Nothing fancy, at least not in the snapshot. The only thing that correlates the failing instances is that their segments are bigger in comparison to thos of other instance, although not by too much. Let me know what you need (or what I can do). Thanks Eliot! >> >> >> Cheers, >> Max

1 0

[urgent] Spur sometimes produces unloadable image segments
by Max Leske 30 May '20

30 May '20

Hi everyone, I desperately need some help with image segments in spur (Pharo). After having tested close to 1000 image segments that were written with a spur VM I have ended up with a couple that can't be loaded. I can reproducibly generate them from our old segements (Squeak 4 VM). Without full confidence in the image segment code I can't upgrade and couldn't upgrade those few instances anyway. I would be very thankful if someone had the time to look into this quickly. I will try to debug it myself but it will probably take me a couple of hours (if not days) until I have succeeded in building a VM that I can debug. Cheers, Max

3 2

VM Maker Inbox: VMMaker.oscog-fn.2757.mcz
by commits＠source.squeak.org 29 May '20

29 May '20

A new version of VMMaker was added to project VM Maker Inbox: http://source.squeak.org/VMMakerInbox/VMMaker.oscog-fn.2757.mcz ==================== Summary ==================== Name: VMMaker.oscog-fn.2757 Author: fn Time: 29 May 2020, 10:29:35.998527 am UUID: 52be099f-82ff-4e19-a4d7-cebeb9271919 Ancestors: VMMaker.oscog-ul.2756 Update and fix SlangTests>>testSimpleMethod after recent sqInt-related changes. =============== Diff against VMMaker.oscog-ul.2756 =============== Item was changed: ----- Method: SlangTests>>testSimpleMethod (in category 'tests') ----- testSimpleMethod | codeGenerator tMethod code | codeGenerator := CCodeGenerator new. tMethod := codeGenerator compileToTMethodSelector: #extBBytecode in: StackInterpreter. self assert: #( #'[' byte #':=' self fetchByte #'.' self fetchNextBytecode #'.' extB #':=' #(numExtB #= 0 and: #'[' byte #> 127 #']') ifTrue: #'[' byte #- 256 #']' ifFalse: #'[' #(extB bitShift: 8) #+ byte #']' #'.' numExtB #':=' numExtB #+ 1 #'.' #'^' self #']') equals: (Scanner new scanTokens: tMethod parseTree printString). code := String streamContents: [:s| tMethod emitCCodeOn: s generator: codeGenerator]. code := code allButFirst: (code indexOfSubCollection: 'sqInt') - 1. self assert: #('sqInt' 'extBBytecode(void)' '{' 'sqInt' 'byte;' 'byte' '=' 'fetchByte();' 'fetchNextBytecode();' 'extB' '=' '((numExtB' '==' '0)' '&&' '(byte' '>' '0x7F)' '?' 'byte' '-' '256' + ':' '((((sqInt)((usqInt)(extB)' '<<' '8))))' '+' 'byte);' - ':' '(((usqInt)' 'extB' '<<' '8))' '+' 'byte);' 'numExtB' '+=' '1;' 'return' 'self;' '}') equals: (code findTokens: Character separators) asArray !

1 0

sk_GENERAL_NAME_freefunc
by stes 27 May '20

27 May '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Because the following has been open for a few weeks, I thought to remind about : https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/496 - --- a/platforms/unix/plugins/SqueakSSL/openssl_overlay.h +++ b/platforms/unix/plugins/SqueakSSL/openssl_overlay.h @@ -164,7 +164,7 @@ #define sqo_SSL_library_init SSL_library_init #define sqo_SSL_load_error_strings SSL_load_error_strings - -#define sk_GENERAL_NAME_freefunc void(*)(void*) +#define sk_GENERAL_NAME_freefunc void(*)(GENERAL_NAME*) #endif Is this OK for you please ? This would be a very useful fix for Solaris. Thanks, David Stes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJezi+NAAoJEAwpOKXMq1MaarAH/Rvd+QL1WZCBTAsX6FuC1cEQ Ssl3eh6+Bduf/T4XIPW66TihjufMjwMiCNrL3EThGZGHPK/VhrQN+Sthqn7DLNfM i516rFLq/nN5PqXrjJtPPPQ3TUZ3hieqxHfl05sjy8RgIgcO7EYqYgU4x0ds3kf9 EORdylu7zmw8ru3SeuvogoUD7ciJByxBbjBz6ViHGR4XH4Hn54JPNln8KEm+GYte hkUuuwrNzt8ZHEvkbkS+qELjaOnm8Tfc7ughBDme9E+DZF3f5yiwMKk4+0CptiOL SHQlq40TR1astJVPXOlG1WO0ZidBZpiUiXuCj52zlK4/ZESbTHhLiMRl71phl6Y= =cMik -----END PGP SIGNATURE----- -- Sent from: http://forum.world.st/Squeak-VM-f104410.html

1 0

Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)
by Shaping 26 May '20

26 May '20

To clarify about the VM fork: few years ago, the transpiled C source code of the VM, along with the genuine C parts and core plugins, were migrated to GitHub under the common name OpenSmalltalk VM, to be shared by Squeak, Pharo, Cuis, and Newspeak. But a few months ago, Pharo eventually decided to fork the repository and proceed to make their desired changes to the VM promptly and without the need for mutual agreement. They can progress faster now, but we have another fork. Why was this done? Are there details I can read about the technical decision process. Eliot’s comment about the forked seemed negative—that it should not have happened. I agree. I don’t have any more details. Since the only shared mailing list at the moment is vm-dev Thanks for saying so. I was wondering. (although I don't know whether that is still true since the fork), that is your best bet. Of course you will miss out Squeak and Pharo members not subscribed to the vm list, Right. Why is there no common list that we all want to watch? That doesn’t seem health, either. so there is not really a nice way to address both communities widely and reliably at the same time and have a connected discussion. That’s what I want. I also want to involve the Verona group in the context of parallelizing the VM Pony-Orca-style or eventually Pony-Verona-style if that happens (which apparently seems to be their objective). I need to talk to those guys first, though. When the time comes to share those convos with Robert and other VM folks, clearly I want as many Pharo and Squeak people as possible to see that. Can we have a common Squeak/Pharo mailing that is not so VM-specific/specialized as to leave some of the Squeak/Pharo contributors/users uninterested in subscribing? “OpenSmalltalk-dev” or “OpenSmalltalk-gen”? Something like that. At least no way that I know of. I just wanted to ensure you are aware of the fact that you might not get counterarguments or other perspectives where some are due. Yes, thank you. Looks like the text editor has diverged in Pharo as well. In Squeak, what I described works (at least in my image and I don't remember changing anything about text editing): you can toggle the selection of a whole word with a separate single click (can be any number of seconds after the first) on the cursor position. Yes, you’re right; the click pattern is as you say in Pharo 9, but it’s still slow. It is however, much faster than Pharo’s text selection, much more tolerable, but still somewhat distracting. VW selection is still much faster than Squeak’s. It is not so in Pharo (I have a Pharo 8 image here), so my speculation about the click handling is no "excuse" that explains the delay there, but maybe the underlying event handling is still waiting for two separate single clicks in a short time frame. Would be nice if someone rectified my assumptions, if they know better. Anyway the selection in Squeak is quick enough for me personally to not be bothered by it. It's just barely okay for me. Does anyone know how the text selection algo works in Squeak and Pharo? By dropping Morphic I meant that as soon as Pharo no longer needs it, they will probably not include it in the "default" image/configuration. As soon as this happens, someone would have to make sure that Morphic still works when loaded into a Pharo image. Right. Does each framework have an unofficial caretaker/maintainer? That’s how it seems. Otherwise Morphic in Pharo will rot and eventually become unusable, and so will applications programmed with Morphic. And I doubt that this maintenance effort of Morphic in Pharo will happen on behalf of the official Pharo leadership. Must maintenance/inclusion of any framework depend on official Pharo leadership? Official pharo leadership == Consortium? Someone has to coordinate? Arbitrate? I don’t know. Vote based on measurements all participants can verify? That’s sounds better. Incidentally, in the early days Pharo adopted several new packages or factoring styles that were not accepted in the default Squeak image yet for whatever reason, coupling them more tightly with the base system. For example, the new file API (not the VM primitives, but the Smalltalk API) which was just an add-on package for Squeak in the beginning, or the usage of Traits in the core packages, which means you cannot unload the Traits package. Traits are becoming part of the basic machinery, aren’t they? I have something I want to do with them. I’m not convinced yet that they are in final form. Is their presence a big problem for anyone? For file handling we need agreement on what works best, so that we can include that in the base image if your image needs to handle files. It should still be unloadable if you don’t want file handling. If Traits are as basic as Class and Behavior, they can’t be unloaded. Do you want Traits to be loadable? If so, we need no-trait and trait-using versions of frameworks, which is probably worse, assuming Traits have general utility, which they do, even if the details need some work. Do you want the file API to be loadable? If so, Traits probably have to stay in the image, because they might be used in the core at some point. If you want Traits to be loadable, a no-traits and trait-using file API may both need to be maintained. The core dependency tree for classes/packages probably isn’t reviewed by every developer before it is fixed in a way that makes change hard. Is that thinking process exposed to the community before a decision is made? Pharo has since then tossed out the original file API and w.r.t. traits may have redefined what "the core" is... Maybe Squeak and Pharo do not mean the same things or do not draw the same lines when they say "completely modularized". With respect to Morphic, maybe Pharo wants to replace some subsystems with more professional-looking alternatives, and not maintain so much self-built technology. It is not entirely impossible to have different UIs in Squeak either (it still has the legacy Smalltalk-80 MVC GUI Do we agree that Spec2 is a better architecture than the original MVC? It’s similar in the basic ways, but uses a pluggable backend renderer. Does anyone still want to use MVC now? Why can’t we still keep it and load it if needed? Does it break something? which you could use instead of Morphic, and there is a basic console interface). The questions are 1) would a particular backend be supported by the official distribution (Morphic in Pharo? GTK in Squeak?), Should we test prototypes of each back end, and decide to include one based on performance results? I’m not sure what “official distribution” means. The distribution would be more fine-grain, a version of a package or a version of a class. I that what it means? 2) which APIs are supported and stable to build applications with (ToolBuilder vs. Morphic vs. GlamorousToolkit vs. Spec vs. Block and Brick vs. GTK-binding vs. whatever), and 3) is anything of the API reliably available in both Squeak and Pharo, without duplicating a lot of code? At the moment, not even the Collection API is entire compatible, as I said. Regarding "Morphic primitives", to my knowledge Morphic builds on the event input primitives, and uses the Graphics API (pens, lines, shapes, colors, fonts etc.) to draw, which in turn relies on BitBlt primitives for rendering. I am not sure whether one could implement Morphic on top of GTK without compromises. I’m not sure either. GTK is very flexible though. With just enough effort, you can probably make anything happen... But the resources of the community are severely limited, especially for Squeak. The aim with a single Smalltalk is to free up resources for future development. There is short-term dev cost to make that happen. Shaping Am Sa., 16. Mai 2020 um 14:47 Uhr schrieb Shaping < <mailto:shaping@uurda.org> shaping(a)uurda.org>: > > > > == First, on the text selection delay issue. == > > > > Now that you mention it, the text seems to get highlighted slightly slower than in native Windows widgets or WordPad (which is what I had available for comparison). But it also behaves differently. > > > > Please try the following and report whether you experience the same > > delay: 1) click into the middle of a word with a single click - it > won't get highlighted, > > > > Correct. > > > > 2) click again at the same cursor position > > > > How soon after? If more than a small fraction of second, this is just another single click. > > > > - the whole word should be selected now. > > > > No, not unless this is a double click. If I do a double click (splitting a double click into two different click locations is almost impossible), then the text highlights with a noticeable delay. > > > > Is the reaction to the second click also too slow? > > > > There is no response to the second click except to place the cursor in the same place again. A rapid sequence of clicks (double-click) must happen to cause selection. > > > > In regular Windows widgets you have to double-click, not click again, to toggle word selection. Your experienced delay might therefore be associated with Squeak/Pharo processing two consecutive single clicks and the OS widgets processing one proper double click event. But that's only speculation on my part, I didn't check the code. > > > > These are Pharo windows, not native Windows windows. I’m doing the tests in a Pharo 9 Playground. It follows the same selection protocol as a native window: a double click. Pharo has its own event loop, like VW, right? > > > > == Second, on the divergence of Pharo and Squeak == from my perspective and I have not been around at the time of the split yet. > > > > A general note: you will obviously get biased views from each side and > the other one might view them as unfairly presented (which makes such > discussions unproductive quickly). Moreover, much of the divergence is > not in the VM but in the image, > > > > No good reason for image divergence has been given yet. The Pharo effort to modularize completely, if successful, gives all Squeak and Pharo Smalltalkers what they want: painless, reliable/predictable, deep fine-grain reconfigurability of the environ. Is there something else to want here? What does the bold stuff not cover? > > > > > > so you might not even be talking to the right people on the Squeak side. Since not everyone is subscribed to both (or all three) mailing lists, they might not see all the answers, so you cannot have a coherent discussion at all. > > > > I might not be mailing to the right lists. Feel free to make suggestions. > > > > To start with the example, I suppose the new preferences look has probably not gotten from Pharo into Squeak not because the Squeak community did not like it, but because it was simply not contributed back. The Squeak folks would have had to pull it and probably did not deem it important enough (or were not even aware if they don't use Pharo regularly). > > > > Yeah, that’s a problem. > > > > Besides, the preferences in Squeak are also not a flat list, they have had categories for ages. > > > > > > The categories are in an alphabetic list. It should be a tree. The list is too long and doesn’t show any organization besides the alphabetic ordering. That’s the point. There is one invisible root and a wide first level—not much branching. Two levels. Also, the subitems in each category are sometimes alphabetic and other time not. I’d have to study the options for a week to determine what I would do differently, but I don’t like the first impression this gives. There is some sense of subcategory, like several contiguous browse* items or syntax* items, but these groups should be in subnodes. I’m seeing three of four levels. I’m not sure. It would take some study. It doesn’t feel coherent and compelling. It doesn’t pull me in. It looks like a bunch of miscellaneous details. The Settings browser makes pretty get sense, yes? > > If the Squeak community was busy all the time pulling things > > > > --Not all the time, just what you can use when you need it. I don’t think the need for tree is perceived beyond the two levels. > > > > back from Pharo, they could not concentrate on their own efforts. > > > > Can you tell me about those efforts? I know the VM is one, maybe the biggest. What else do Squeak folks work on? > > I also understand why the developers of the new Pharo preferences tree did not like to invest the same effort in Squeak. What incentive would they have? > > > > Make all features (GUIs/frameworks) loadable into a new, mostly empty image. Make all aware of those features. Knowing that this will happen for all feature-work contemplated will lower the threshold to doing the feature-work. A Squeak dev will learn about the Settings feature, for example, and adapt it if he wants. If we have the same basic graphical framework, there is nothing to adapt (to Morphic). It just works. Yes, the transition is painful. And there is always a new transition coming as new tech surfaces. We need a way to deal with that systematically without killing creativity and without creating so much disruption that commercial interests are wary of the environ. > > > > And here we are. Such differences and the additional effort are the liability of a fork, for both sides. Some people are or were active in both communities to invest the effort. For example, Eliot also provided the image side of VM improvements to Pharo, not only Squeak, if I remember correctly. I don't know whether he still does that since the fork of the VM. > > > > What fork of the VM? Please explain. > > > > Pharo would like to get rid of Morphic; as far as I know, Squeak embraces Morphic for its direct manipulation interface and UI discoverability (inspecting Morphs and such). > > > > Right. > > > > GTK has its inspector, but I don't know whether you get the same features out of it. Direct manipulation probably not, only indirect. And can you control that inspector from Pharo or do you have to write C code to change it in GTK itself? From my impression, this would be a no-go for Squeak. The tools must be maintainable in Smalltalk, working with C is a necessary evil in the VM. Maybe Pharo has found a way to have the best of both worlds, I don't know. > > > > I don’t know much about GTK yet. I’ll get to it. > > > > Still that leaves all Morphic applications behind; their UI (or even the entire program) would have to be rewritten from scratch. I doubt that Pharo will keep Morphic workable once they can drop it from the mainline. > > > > I don’t understand. Drop? Why? If Morphic works and someone wants it, then keep it. Are you saying it would be dropped because it cannot be satisfactorily re-implemented with the GTK3 backend? What’s wrong with keeping Morphic primitives? > > > > And Spec2 is not the first new idea of UI technology in Pharo, you know. In return, the different technology makes it harder for Squeak to port new features even if they wanted to, making it less likely to happen. Even some basic Collection API has changed in Pharo (string trimming and joining for example), now try to keep your code compatible with both without messing it up... > > > > Yes. The “port” is only difficult once if the aim is thereafter to work from a common base image. But there will be more ports and conversions. Is there a system on either side for managing incorporation of new tech, libraries, and standards? > > The compatibility and porting problems are offloaded to the application and library developers, even between Pharo releases. I don't know how this can be advertised as appealing to commercial development. VisualWorks & Co. > > could certainly not deal with their users that way. > > > > This happens in any case. That it happens in one image and not two is better. > > > > > > I don't think that Pharo does bad stuff in general, in fact their work could be very good (I don't look at it regularly and certainly don't follow the implementation). Like you said, disentangling, modularization, test automation, and innovation are valuable goals. > > Squeak mostly agrees on the goals, but does not pursue them in the same disruptive manner. Probably this is the "pushback" you have been told of... > > > > Right. How does squeak do things less disruptively? I agree that the innovation on the Pharo side is accompanied by almost as much bloat and confusion, especially for new comers trying to port. What is the Squeak way of improving the frameworks and using new tech, like 3rd part libs? > > > > If Spec is a UI generalization framework that makes it independent > from the graphics implementation, > > > > Yes, that’s the aim. > > > > then one should rather compare it to Squeak's ToolBuilder, not Morphic. ToolBuilder as well could have different targets, such as GTK, (I have seen Squeak tools rendered with some Java UI Framework a few months ago) but nobody pushes that in the Squeak trunk. There was no voiced demand. > > > > I don’t know ToolBuilder. Perhaps I should have a look. Why would the best of both TB and Spec2 not be used in a common base tool-building framework, which sounds broader than what Spec2 does, but may not be? I don’t know enough of TB to say. > > > > How is framework adoption/inclusion decided? The dev who writes the framework first and demonstrates utility first with that framework will have it included in the base image? Just thinking aloud. How does it work? How do you want it to work? > > > > I haven't participated in such discussions of the right way™ in the past, but my impression from what I heard so far is that Pharo pushes forward rigorously and does not look back, and if it does, then sometimes with a disparaging or snappy tone. > > > > Does this mean that Pharo folks are unfairly critical of old frameworks in order to push the new thing (whatever it is) along? > > > > Some of the Squeak guys are therefore very sceptical about Pharo and their attitude, to say the least, and sometimes also talk harshly. > > > > I can see how that might happen. Too many changes too quickly doesn’t look like innovation to some. It looks risky, especially to commercial interests, but clearly the consortium don’t want this view. It’s not healthy for Pharo or Smalltalk. > > > > The recent fork of the VM further deepens the trenches, > > > > Okay, this must have been the fork I saw Eliot mention a few weeks back. I don’t know the details, but it sounds like a bad idea. > > > > especially since the foundation of "OpenSmalltalk" VM (no longer > "Squeak" VM) was in my perception a commitment to cooperate at least > on that end. There are probably only a bunch of persons who are > responsible for the bad mood, and I assume that the majority of both > communities are in fact friendly people. :-) > > > > So it seems, but I don’t know the details. I prefer to focus on the tech, not personalities and self-esteem issues. > > > > Thanks for the perspective. > > > > > > Shaping > > > > > > > > > > > > Am Sa., 16. Mai 2020 um 08:40 Uhr schrieb Shaping < <mailto:shaping@uurda.org> shaping(a)uurda.org>: > > > > > > > > > > > > Why can’t the OSVM be a single, unforked, maxed-out VM with all the best and fastest features working in Squeak and Pharo? Why did the split happen? > > > > > > > > > > > > In very general terms, the fork was due to their being Group A > > wanting > > > to go one direction and Group B wanting to go in a different direction. i.e.... > > > > > > B says "We want to do X". > > > > > > A says "We don't want to do X." > > > > > > B says "We really want to do X." > > > > > > A says "Definitely no." > > > > > > B says "We really want to do X and actually we're doing it over here." > > > > > > > > > > > > Lol Thanks for the explanation. That’s more or less what I thought. > > > > > > > > > > > > But can’t the differences be setup at config-your-environ time instead of build time, when the task is heavier and slower? > > > > > > > > > > > > In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. > > > > > > > > > > > > I like disentangling and modularizing. I suppose this is a universal like. > > > > > > > > > > > > They also wanted to move to a reproducible-build-system where each > > > change "bootstrapped" a nightly image from an empty file, > > > > > > > > > > > > I like this too. > > > > > > > > > > > > whereas Squeak continues to use a "continuous evolution" model. > > > > > > > > > > > > Don’t both groups want the automatic building and testing the Consortium is talking about recently? > > > > > > > > > > > > I’m not sure I understand how “continuous evolution” works. Sounds like there is lots of wiggle room in that idea. Don’t we need some structure? We seem to be getting that in Pharo. > > > > > > > > > > > > I’m not sure about Squeak. The GUI tools/menus still feel hodgepodge (much nicer, but still not well organized) 16 years later. I used it between 2002 to 2004, and then again just a few days ago. I like the faster debugger and the flat GUIs, but I don’t need Morphic to have those dev-tool GUIs. I’d prefer to rework the GUIs with Spec2/GTK3, and keep the flat, clean, button-packed look with some improvements (like the new Spec2 selection highlighting pattern, which is very nice). The rest of Squeak seems messy. > > > > > > > > > > > > I do very much like the technical, concrete feel of Squeak’s details about the VM. That reminds me of old times and why I got involved in computers, and it supports my current interest in VM parallelization. Those VM details need a somewhat different shape/presentation. There is a beauty in Squeak, but the eviron still feels a bit rough. > > > > > > > > > > > > For example, why aren’t all those preferences in a tree where you can actually find things because they are categorized. It’s a big list. That seems very strange in 2020. Why don’t Squeak folks borrow the Pharo Settings GUI idea, and implement that in Morphic, as they like? I thought more would have happened in the Squeak GUI in 16 years, but I’ve not seen all of 5.3 yet. I’m still poking around. I suppose most of the improvements are in the VM, which I imagine absorbs most of the group’s energy. > > > > > > > > > > > > And there are more reasons I probably not aware of. > > > > > > Here is the Pharo Vision document circa 2012 which inspired me > > > <https://hal.inria.fr/hal-01879346/document> https://hal.inria.fr/hal-01879346/document > > > > > > > > > > > > Thank you. I will read it. Is the Consortium updating that doc? There was a doc recently from Stef that looks like it belongs in there, merged somehow. > > > > > > > > > > > > It looks like a bad use of energy in a community that is small and needs to use its human resources efficiently. > > > > > > > > > > > > Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. > > > > > > > > > > > > Agreed. I don’t understand the pushback because I don’t understand Squeak folks’ objection to rigorous, systematic, automatic testing and disentangling/modularizing of frameworks. They are probably fine with all that. Do Squeak folks have a document that defines “continuous development.” I know that VM testing is automated. I don’t see how the objectives are so different, at least on the automation front. Everyone seems to agree that CI is good. > > > > > > > > > > > > > > > > > > I want to help, but need to port first from VW, and I’m trying to choose Squeak or Pharo. Both have speed problems. Squeak has fewer, but Pharo could be much faster with broad use of Spec2. > > > > > > > > > > > > Would reintegrating Squeak and Pharo development make more sense? > > > > > > > > > > > > I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. > > > > > > > > > > > > I never liked the halo thing. It’s okay. It seemed/seems too busy and distracting. I think Morphic and the “too many cooks” problem is why I broke off in 2004. > > > > > > > > > > > > If we are fully modular, and you love Morphic, and want to live there mentally and visually, all the time, then load the Morphic package into the new universal OpenSmalltalk. Have all your GUIs built with Morphic. Have cute little morphs stuck here and there. Knock yourself out. Don’t like Morphic? Don’t think it’s cute? Load the more business-like-but-not-boring Spec2. I don’t see an insurmountable technical problem here. > > > > > > > > > > > > > > > > > > This is one of the reasons that Spec was created - to be independence layer. > > > IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. > > > > > > > > > > > > Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection slowness problem, which is everywhere in Pharo and Squeak. I’ve mentioned this a few times recently—of all the goofy things to prevent a port from VW…..Okay, that and Pharo’s slow debugger. Two things keep me out of Pharo/Squeak. I don’t love VW. I tolerate it really well. That’s different. J > > > > > > > > > > > > wrt the VM, Pharo want to remove all native-windowing from the VM, > > so > > > that window opening > > > > > > is controlled from the Image via FFI rather than the VM. > > > > > > > > > > > > I agree with the objective. > > > > > > > > > > > > This conflicts with Squeak's backward comparability goals. > > > > > > > > > > > > Okay, this is the real problem. > > > > > > > > > > > > So there is a ton of old Squeak code that no one is willing to rework in order to be compatible with the new vision for native-windowing independence. Perhaps someone can give more details on that old code. > > > > > > I suppose many Squeak folks bemoan all the extra work needed for a recoding. Is this still really an issue? Maybe very little of that old code is still being used in business-critical ways. The need for a recoding may not be the big issue it once was. > > > > > > > > > > > > This change would effectively create more devs willing to work on any problem. This change would also prevent fracturing of feature-sets across the two Smalltalks from happening in the first place. > > > > > > > > > > > > I personally had the inspiration that Squeak might be based off the > > > Pharo Headless Bootstrap, > > > > > > but in the end I didn't find the time to push this further. > > > > > > > > > > > > That’s a very good idea. Why don’t all the Squeak folks work on it? Are you the only one pushing for this? > > > > > > > > > > > > > > > > > > Squeak and Pharo GUI styles are different. So be it. Can’t the GUI frameworks and conventions be separated in the same image, and configured as desired in GUI sections of Settings? > > > > > > > > > > > > Pharo currently can use both Morphic and GTK3 for its GUI backend. > > > Possibly the GTK3 backend would provide some speed benefit (??) > > > > > > > > > > > > It’s a good question. Is the core Morphic issue whether GTK3 can render non-rectangular shapes efficiently? There’s a lot of that in Morphic. I suppose it’s the main concern. Even if Morphic relies on special drawing primitives, they can go in a lib and be accessed via FFI. > > > > > > > > > > > > Shaping > > > >

14 26

VM Maker: GDB-bgs.3.mcz
by commits＠source.squeak.org 26 May '20

26 May '20

Boris G. Shingarov uploaded a new version of GDB to project VM Maker: http://source.squeak.org/VMMaker/GDB-bgs.3.mcz ==================== Summary ==================== Name: GDB-bgs.3 Author: bgs Time: 26 May 2020, 5:24:25.12793 pm UUID: 8de059b8-c7b7-4943-80e4-f10d5993d794 Ancestors: GDB-bgs.2 Execution on non-simulated hardware. =============== Diff against GDB-bgs.1 =============== Item was changed: ----- Method: FakeProcessorDescriptionX86 class>>fakeFeatures (in category 'as yet unclassified') ----- fakeFeatures + ^TargetAwareX86 isHardware + ifTrue: [self fakeFeaturesStockSilicon] + ifFalse: [self fakeFeaturesGem5]! - ^#( - #('eax' 32) #('ecx' 32) #('edx' 32) #('ebx' 32) #('esp' 32) #('ebp' 32) #('esi' 32) #('edi' 32) - #('eip' 32) #('eflags' 32) #('cs' 32) #('ss' 32) #('ds' 32) #('es' 32) #('fs' 32) #('gs' 32) - ) - " - #('st0' 80) #('st1' 80) #('st2' 80) #('st3' 80) #('st4' 80) #('st5' 80) #('st6' 80) #('st7' 80) - - #('fctrl' 32) - #('fstat' 32) - #('ftag' 32) - #('fiseg' 32) - #('fioff' 32) - #('foseg' 32) - #('fooff' 32) - #('fop' 32) - ) - "! Item was added: + ----- Method: FakeProcessorDescriptionX86 class>>fakeFeaturesGem5 (in category 'as yet unclassified') ----- + fakeFeaturesGem5 + ^#( + #('eax' 32) #('ecx' 32) #('edx' 32) #('ebx' 32) #('esp' 32) #('ebp' 32) #('esi' 32) #('edi' 32) + #('eip' 32) #('eflags' 32) #('cs' 32) #('ss' 32) #('ds' 32) #('es' 32) #('fs' 32) #('gs' 32) + )! Item was added: + ----- Method: FakeProcessorDescriptionX86 class>>fakeFeaturesStockSilicon (in category 'as yet unclassified') ----- + fakeFeaturesStockSilicon + ^#( + #('eax' 32) #('ecx' 32) #('edx' 32) #('ebx' 32) #('esp' 32) #('ebp' 32) #('esi' 32) #('edi' 32) + #('eip' 32) #('eflags' 32) #('cs' 32) #('ss' 32) #('ds' 32) #('es' 32) #('fs' 32) #('gs' 32) + + #('st0' 80) #('st1' 80) #('st2' 80) #('st3' 80) #('st4' 80) #('st5' 80) #('st6' 80) #('st7' 80) + #('fctrl' 32) #('fstat' 32) #('ftag' 32) #('fiseg' 32) #('fioff' 32) #('foseg' 32) #('fooff' 32) #('fop' 32) + + "sse" + #('xmm0' 128) #('xmm1' 128) #('xmm2' 128) #('xmm3' 128) #('xmm4' 128) #('xmm5' 128) #('xmm6' 128) #('xmm7' 128) + #('mxcsr' 32) + + #('orig_eax' 32) + ) + + ! Item was added: + ----- Method: FakeProcessorDescriptionX86>>z1kind (in category 'as yet unclassified') ----- + z1kind + ^1! Item was changed: + SharedRAM subclass: #Gem5SharedRAM + instanceVariableNames: 'tlb' - RemoteRAM subclass: #Gem5SharedRAM - instanceVariableNames: 'tlb hostPtr shmemSize' classVariableNames: '' poolDictionaries: '' category: 'GDB-RSP'! Item was removed: - ----- Method: Gem5SharedRAM class>>gem5: (in category 'FFI') ----- - gem5: nBytes - "Answer the void* pointer to the backing store of the gem5 guest memory." - | fd addr | - fd := self shmOpen: '/gem5' - with: 64"O_CREAT" | 2"O_RDWR" - with: 8r666. "mode" - addr := self mmap: 0 - with: nBytes - with: 1"PROT_READ" | 2"PROT_WRITE" - with: 1 "MAP_SHARED" - with: fd - with: 0. - ^addr - - " - Gem5SharedRAM halt; gem5: 5000 - " - ! Item was removed: - ----- Method: Gem5SharedRAM class>>mmap:with:with:with:with:with: (in category 'FFI') ----- - mmap: addr with: length with: prot with: flags with: fd with: offset - <cdecl: void* 'mmap' (longlong longlong long long long longlong) module: '/lib/x86_64-linux-gnu/libc.so.6'> - ^self externalCallFailed - ! Item was removed: - ----- Method: Gem5SharedRAM class>>mmuPageSize (in category 'granularity') ----- - mmuPageSize - ^4096! Item was removed: - ----- Method: Gem5SharedRAM class>>offsetMask (in category 'granularity') ----- - offsetMask - ^self mmuPageSize - 1! Item was removed: - ----- Method: Gem5SharedRAM class>>pageMask (in category 'granularity') ----- - pageMask - ^16rFFFFFFFF bitXor: self offsetMask - ! Item was removed: - ----- Method: Gem5SharedRAM class>>shmOpen:with:with: (in category 'FFI') ----- - shmOpen: name with: oflag with: mode - <cdecl: ulong 'shm_open' (char* ulong ulong) module: '/lib/x86_64-linux-gnu/librt.so.1'> - ^self externalCallFailed - ! Item was removed: - ----- Method: Gem5SharedRAM>>byteAtAddr:put: (in category 'writing') ----- - byteAtAddr: byteAddress put: byte - | ptr | - byteAddress = 16r109014 ifTrue: [self halt]. - ptr := self translate: byteAddress. - ptr unsignedByteAt: 1 put: byte! Item was removed: - ----- Method: Gem5SharedRAM>>fillFromStream:startingAt:count: (in category 'writing') ----- - fillFromStream: aFileStream startingAt: startAddress count: count - | contents | - contents := aFileStream next: count. - self writeBytes: contents toAddr: startAddress. - ^contents size! Item was removed: - ----- Method: Gem5SharedRAM>>forceRead32At: (in category 'address translation') ----- - forceRead32At: addr - | x | - self halt. "I don't remember why this was needed." - x := super read32At: addr. - tlb := self getTLB. - ^x - ! Item was removed: - ----- Method: Gem5SharedRAM>>forceReadAt:nBytes: (in category 'address translation') ----- - forceReadAt: addr nBytes: n - super readAt: addr nBytes: n. - tlb := self getTLB! Item was removed: - ----- Method: Gem5SharedRAM>>forceWriteBytes:toAddr: (in category 'address translation') ----- - forceWriteBytes: aByteArray toAddr: addr - | x | - x := super writeBytes: aByteArray toAddr: addr. - tlb := self getTLB. - ^x - ! Item was removed: - ----- Method: Gem5SharedRAM>>forceWriteInt32:toAddr: (in category 'address translation') ----- - forceWriteInt32: int toAddr: addr - | x | - x := super writeInt32: int toAddr: addr. - tlb := self getTLB. - ^x - ! Item was removed: - ----- Method: Gem5SharedRAM>>getTLB (in category 'RSP') ----- - getTLB - | answer | - answer := self gdb q: '.'. - answer isEmpty ifTrue: [ self error: 'GDB failed to return TLB' ]. - ^Dictionary newFromAssociations: - (((answer findTokens: ';') - collect: [ :s | s findTokens: ':' ]) - collect: [ :pair | (Integer readFrom: pair first base: 16) -> (Integer readFrom: pair last base: 16) ])! Item was removed: - ----- Method: Gem5SharedRAM>>hostPtr (in category 'shmem') ----- - hostPtr - hostPtr isNil ifTrue: [ hostPtr := Gem5SharedRAM gem5: shmemSize ]. - ^hostPtr! Item was removed: - ----- Method: Gem5SharedRAM>>longAtAddr:put:bigEndian: (in category 'writing') ----- - longAtAddr: addr put: aValue bigEndian: bigEndian - | ptr int | - int := bigEndian - ifTrue: [ aValue byteSwap32 ] - ifFalse: [ aValue ]. - ptr := self translate: addr. - ptr unsignedLongAt: 1 put: int - - - - ! Item was removed: - ----- Method: Gem5SharedRAM>>read:bytesAtAddr: (in category 'reading') ----- - read: n bytesAtAddr: addr - | backingAddr | - backingAddr := self translate: addr. - ^((1 to: n) collect: [ :idx| backingAddr byteAt: idx ]) asByteArray - ! Item was removed: - ----- Method: Gem5SharedRAM>>shmemSize (in category 'shmem') ----- - shmemSize - ^shmemSize! Item was removed: - ----- Method: Gem5SharedRAM>>shmemSize: (in category 'shmem') ----- - shmemSize: howBig - shmemSize := howBig! Item was changed: ----- Method: Gem5SharedRAM>>tlb (in category 'address translation') ----- tlb tlb isNil ifTrue: [ tlb := self getTLB ]. ^tlb! Item was removed: - ----- Method: Gem5SharedRAM>>translate: (in category 'address translation') ----- - translate: addr - | pageAddr | - pageAddr := self virt2phys: addr. - pageAddr isNil ifTrue: [ ^ self error forceRead32At: addr ]. - ^self hostPtr getHandle + pageAddr. - ! Item was removed: - ----- Method: Gem5SharedRAM>>unsignedLongAtAddr:bigEndian: (in category 'reading') ----- - unsignedLongAtAddr: addr bigEndian: bigEndian - | backingAddr int | - backingAddr := self translate: addr. - int := backingAddr unsignedLongAt: 1. - bigEndian ifTrue: [ int := int byteSwap32]. - ^int! Item was changed: ----- Method: Gem5SharedRAM>>virt2phys: (in category 'address translation') ----- virt2phys: anAddress " Answer the physical address for the given virtual address, if it is mapped, nil otherwise. " | pageVirt pagePhys | pageVirt := anAddress bitAnd: self class pageMask. pagePhys := self tlb at: pageVirt ifAbsent: [ ^nil ]. ^pagePhys bitOr: (anAddress bitAnd: self class offsetMask)! Item was removed: - ----- Method: Gem5SharedRAM>>writeBytes:toAddr: (in category 'writing') ----- - writeBytes: aByteArray toAddr: addr - | ptr | - addr = 16r109014 ifTrue: [self halt]. - ptr := self translate: addr. - aByteArray doWithIndex: [ :x :idx | ptr unsignedByteAt: idx put: x ] "is there a faster way?" - ! Item was changed: + ThinshellDoodle subclass: #HardwareBreakpointDoodle - PPCgem5ThinshellDoodle subclass: #HardwareBreakpointDoodle instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'GDB-Doodles'! Item was changed: ----- Method: HardwareBreakpointDoodle>>hostIP (in category 'target connection') ----- hostIP + ^'192.168.75.2' + ! - ^'192.168.75.2'! Item was added: + ----- Method: HardwareBreakpointDoodle>>initialPC (in category 'tests') ----- + initialPC + ^16r10000000! Item was changed: ----- Method: HardwareBreakpointDoodle>>installBrk (in category 'tests') ----- installBrk + gdb insertHWBreakpointAt: self initialPC + 15 "3 loads"! - gdb insertHWBreakpointAt: self initialPC + 8! Item was changed: ----- Method: HardwareBreakpointDoodle>>pdl (in category 'target connection') ----- pdl + ^FakeProcessorDescriptionX86 new + ! - ^FakeProcessorDescriptionPPC new! Item was added: + ----- Method: HardwareBreakpointDoodle>>tcpPort (in category 'target connection') ----- + tcpPort + ^7000 + ! Item was changed: ----- Method: HardwareBreakpointDoodle>>testHWBrk (in category 'tests') ----- testHWBrk " HardwareBreakpointDoodle new halt; testHWBrk. " + | regs | self connectGdb; installBrk. + regs := gdb getRegisters. + self assert: (regs at: 'eip') = self initialPC. + self assert: (regs at: 'eax') ~= 16r12345678. + self assert: (regs at: 'ebx') ~= 16r12345678. + self assert: (regs at: 'ecx') ~= 16r12345678. + self assert: (regs at: 'edx') ~= 16r12345678. - gdb c. - self assert: gdb pc equals: self initialPC + 8. - self fillNZone. + gdb c. + regs := gdb getRegisters. + self assert: (regs at: 'eip') = (self initialPC + 15). + self assert: (regs at: 'eax') = 16r12345678. + self assert: (regs at: 'ebx') = 16r12345678. + self assert: (regs at: 'ecx') = 16r12345678. + self assert: (regs at: 'edx') ~= 16r12345678. + + [ gdb kill ] on: GdbChildExited do: [ ^self ]. + self error: 'gdbserver did not disconnect'! - "No need to advance, because this is not a trap." - [ gdb c ] on: GdbChildExited do: [ ^self ]. - self error! Item was added: + ----- Method: P1025ThinshellDoodle>>host (in category 'target connection') ----- + host + ^#svost! Item was removed: - ----- Method: P1025ThinshellDoodle>>hostIP (in category 'target connection') ----- - hostIP - ^'192.168.75.199'! Item was removed: - ----- Method: P1025ThinshellDoodle>>pdl (in category 'target connection') ----- - pdl - ^FakeProcessorDescriptionP1025 new! Item was added: + ----- Method: PPCThinshellDoodle>>host (in category 'target connection') ----- + host + "We experiment with PowerPC on either a physical dev board (P1025), + or on gem5. Concrete doodles must answer #svost or #gem5." + ^self subclassResponsibility! Item was added: + ----- Method: PPCThinshellDoodle>>hostIP (in category 'target connection') ----- + hostIP + self host = #svost ifTrue: [^'192.168.75.199']. + self host = #gem5 ifTrue: [^'192.168.75.2']. + self error: 'what host is this?'! Item was added: + ----- Method: PPCThinshellDoodle>>pdl (in category 'target connection') ----- + pdl + self host = #svost ifTrue: [^FakeProcessorDescriptionP1025 new]. + self host = #gem5 ifTrue: [^FakeProcessorDescriptionPPC new]. + self error: 'what host is this?'! Item was added: + ----- Method: PPCgem5ThinshellDoodle>>host (in category 'target connection') ----- + host + ^#gem5! Item was removed: - ----- Method: PPCgem5ThinshellDoodle>>hostIP (in category 'target connection') ----- - hostIP - ^'192.168.75.2'! Item was removed: - ----- Method: PPCgem5ThinshellDoodle>>pdl (in category 'target connection') ----- - pdl - ^FakeProcessorDescriptionPPC new! Item was changed: RemoteGDBTransport subclass: #RemoteGDB + instanceVariableNames: 'packetSize processorDescription tStatus why supported vCont registerCache' - instanceVariableNames: 'packetSize processorDescription tStatus why supported vCont' classVariableNames: '' poolDictionaries: '' category: 'GDB-RSP'! Item was changed: ----- Method: RemoteGDB>>analyzeContinueAnswerT: (in category 'stop codes') ----- analyzeContinueAnswerT: answer | signal textPairs importantRegs thread core stopReason stopArgument | signal := self signalNumberFrom: answer. textPairs := answer copyFrom: 3 to: answer size. textPairs := textPairs findTokens: ';'. importantRegs := Dictionary new. core := nil. thread := nil. stopReason := nil. stopArgument := nil. textPairs do: [ :textPair | | pair k v | pair := textPair findTokens: ':'. k := pair first. v := pair second. (self recognizedStopCodes includes: k) ifTrue: [ stopReason := k. stopArgument := v ] ifFalse: [ k = 'thread' ifTrue: [ thread := v ] ifFalse: [ k = 'core' ifTrue: [ core := v ] ifFalse: [ importantRegs at: k put: (Integer readFrom: k base: 16) "TODO: Missing the reserved case; this will be handled by catching exception in #readFrom: and discarding it" ]]]]. + "TODO: wrap all these things in the DebugStopped" + ^DebugStopped onSignalNum: signal! - self shouldBeImplemented "In TAM, this simply returns; processing is done in the sender after this call." - ! Item was changed: ----- Method: RemoteGDB>>c (in category 'RSP commands') ----- c " Continue. " | answer | + self resetRegisterCache. answer := self q: 'c'. "NB: on some platforms, we have wanted 'vCont;c'. I forgot why." ^self analyzeContinueAnswer: answer! Item was changed: + ----- Method: RemoteGDB>>getRegisters (in category 'register cache') ----- - ----- Method: RemoteGDB>>getRegisters (in category 'RSP commands') ----- getRegisters + registerCache isNil ifTrue: [ registerCache := self getRegistersFromRSP ]. + ^registerCache! - | answer stream | - answer := self q: 'g'. - stream := ReadStream on: answer - from: 1 - to: answer size. - ^self decodeGPacket: stream! Item was added: + ----- Method: RemoteGDB>>getRegistersFromRSP (in category 'RSP commands') ----- + getRegistersFromRSP + | answer stream | + answer := self q: 'g'. + stream := ReadStream on: answer + from: 1 + to: answer size. + + ^self decodeGPacket: stream! Item was changed: ----- Method: RemoteGDB>>insertHWBreakpointAt: (in category 'general query commands') ----- insertHWBreakpointAt: addr | answer | answer := self q: 'Z1,', addr printStringHex, + ',', + self z1kind printStringHex. - ',4'. answer = 'OK' ifFalse: [ self error ]! Item was added: + ----- Method: RemoteGDB>>resetRegisterCache (in category 'register cache') ----- + resetRegisterCache + registerCache isNil ifFalse: [self sendRegistersToRSP]. + registerCache := nil! Item was changed: ----- Method: RemoteGDB>>s (in category 'RSP commands') ----- s "Single step. Return control with signal 5 (TRAP), or if the execution of the current instruction failed, with whatever signal happened." | answer | + self resetRegisterCache. answer := self q: 's'. ^self analyzeContinueAnswer: answer ! Item was added: + ----- Method: RemoteGDB>>sendRegistersToRSP (in category 'RSP commands') ----- + sendRegistersToRSP + | answer stream registerTransfers | + stream := WriteStream on: String new. + registerTransfers := processorDescription regsInGPacket. + registerTransfers do: [ :rt | + rt write: registerCache to: stream ]. + + answer := self q: 'G', stream contents. + answer = 'OK' ifFalse: [self error: answer]! Item was changed: + ----- Method: RemoteGDB>>setRegisters: (in category 'register cache') ----- - ----- Method: RemoteGDB>>setRegisters: (in category 'RSP commands') ----- setRegisters: aDict + self shouldBeImplemented! - | answer stream registerTransfers | - stream := WriteStream on: String new. - registerTransfers := processorDescription regsInGPacket. - registerTransfers do: [ :rt | - rt write: aDict to: stream ]. - - answer := self q: 'G', stream contents. - answer = 'OK' ifFalse: [self error: answer]! Item was added: + ----- Method: RemoteGDB>>z1kind (in category 'general query commands') ----- + z1kind + ^processorDescription z1kind! Item was changed: ----- Method: RemoteGDBSession>>setRegister:to: (in category 'accessing') ----- setRegister: r to: x + self getRegisters at: r put: x + ! - | regs | - regs := self getRegisters. - regs at: r put: x. - self setRegisters: regs! Item was changed: ----- Method: RemoteMemoryDoodle>>testLowLevelWrite (in category 'tests-reading') ----- testLowLevelWrite " RemoteMemoryDoodle new testLowLevelWrite " | goodAddress | self connectGdb. goodAddress := self initialPC. memory writeBytes: #[1 2 3 4] toAddr: goodAddress. self assert: (memory unsignedLongAtAddr: goodAddress bigEndian: true) equals: 16r01020304. self assert: (memory unsignedLongAt: goodAddress + 1 bigEndian: true) equals: 16r01020304. self assert: (memory read: 4 bytesAtAddr: goodAddress) equals: #[1 2 3 4]. + self assert: (memory unsignedByteAtAddr: goodAddress) equals: 1. + self assert: (memory unsignedByteAtAddr: goodAddress+1) equals: 2. - self assert: (memory unsignedByteAtAddr: 16r10000080) equals: 1. - self assert: (memory unsignedByteAtAddr: 16r10000081) equals: 2. [ gdb kill ] on: GdbChildExited do: [ ^self ] ! Item was added: + ----- Method: RemoteRAM>>long64At: (in category 'reading') ----- + long64At: byteIndex + ^self signedLong64At: byteIndex! Item was changed: + ----- Method: RemoteRAM>>long64At:put: (in category 'writing') ----- - ----- Method: RemoteRAM>>long64At:put: (in category 'reading') ----- long64At: byteIndex put: aValue | lowBits mask wordIndex | (lowBits := byteIndex - 1 \\ 4) = 0 ifTrue: [self "N.B. Do the access that can fail first, before altering the receiver" longAt: byteIndex + 4 put: (aValue bitShift: -32); unsignedLongAt: byteIndex put: (aValue bitAnd: 16rffffffff). ^aValue]. "There will always be three accesses; two partial words and a full word in the middle" wordIndex := byteIndex - 1 // 4 + 1. aValue < 0 ifTrue: [(aValue bitShift: -32) < -2147483648 ifTrue: [^self errorImproperStore]] ifFalse: [16r7FFFFFFF < (aValue bitShift: -32) ifTrue: [^self errorImproperStore]]. mask := 16rFFFFFFFF bitShift: 4 - lowBits * -8. self at: wordIndex put: (((self at: wordIndex) bitAnd: mask) bitXor: ((aValue bitShift: lowBits * 8) bitAnd: mask bitInvert32)). self at: wordIndex + 1 put: ((aValue bitShift: 4 - lowBits * -8) bitAnd: 16rFFFFFFFF). self at: wordIndex + 2 put: (((self at: wordIndex + 2) bitAnd: mask bitInvert32) bitXor: ((aValue bitShift: 4 - lowBits + 4 * -8) bitAnd: mask)). ^aValue! Item was added: + ----- Method: RemoteRAM>>longAt: (in category 'reading') ----- + longAt: byteIndex + ^self unsignedLongAtAddr: byteIndex - 1 bigEndian: false! Item was added: + ----- Method: RemoteRAM>>longAt:bigEndian: (in category 'reading') ----- + longAt: anInteger bigEndian: aBoolean + ^self unsignedLongAt: anInteger bigEndian: aBoolean ! Item was added: + ----- Method: RemoteRAM>>unsignedByteAt:put: (in category 'writing') ----- + unsignedByteAt: index put: byte + ^self byteAt: index put: byte! Item was added: + ----- Method: RemoteRAM>>unsignedLongAt: (in category 'reading') ----- + unsignedLongAt: byteIndex + ^self unsignedLongAt: byteIndex bigEndian: self isBigEndian! Item was added: + ----- Method: RemoteRAM>>unsignedShortAt: (in category 'reading') ----- + unsignedShortAt: byteIndex + ^self unsignedShortAtAddr: byteIndex - 1! Item was added: + ----- Method: RemoteRAM>>unsignedShortAt:put: (in category 'writing') ----- + unsignedShortAt: byteIndex put: aValue + "Compatiblity with the ByteArray & Alien methods of the same name." + ^self unsignedShortAtAddr: byteIndex - 1 put: aValue! Item was added: + ----- Method: RemoteRAM>>unsignedShortAtAddr: (in category 'writing') ----- + unsignedShortAtAddr: addr + ^self unsignedShortAtAddr: addr bigEndian: self isBigEndian! Item was added: + ----- Method: RemoteRAM>>unsignedShortAtAddr:put: (in category 'writing') ----- + unsignedShortAtAddr: addr put: aValue + "Compatiblity with the ByteArray & Alien methods." + self isBigEndian ifTrue: [self error]. + (aValue < 0 or: [aValue > 16rFFFF]) ifTrue: [^self errorImproperStore]. + (addr bitAnd: 1) = 0 ifFalse: [ self error: 'Unaligned short store not yet implemented' ]. + self byteAtAddr: addr put: (aValue bitAnd: 16rFF). + self byteAtAddr: addr+1 put: (aValue bitAnd: 16rFF00)>>8. + ^aValue! Item was added: + RemoteRAM subclass: #SharedRAM + instanceVariableNames: 'hostPtr shmemSize' + classVariableNames: '' + poolDictionaries: '' + category: 'GDB-RSP'! Item was added: + ----- Method: SharedRAM class>>gem5: (in category 'FFI') ----- + gem5: nBytes + "Answer the void* pointer to the backing store of the gem5 guest memory." + | fd addr | + fd := self shmOpen: '/gem5' + with: 64"O_CREAT" | 2"O_RDWR" + with: 8r666. "mode" + addr := self mmap: 0 + with: nBytes + with: 1"PROT_READ" | 2"PROT_WRITE" + with: 1 "MAP_SHARED" + with: fd + with: 0. + ^addr + + " + Gem5SharedRAM halt; gem5: 5000 + " + ! Item was added: + ----- Method: SharedRAM class>>mmap:with:with:with:with:with: (in category 'FFI') ----- + mmap: addr with: length with: prot with: flags with: fd with: offset + <cdecl: void* 'mmap' (longlong longlong long long long longlong) module: '/lib/x86_64-linux-gnu/libc.so.6'> + ^self externalCallFailed + ! Item was added: + ----- Method: SharedRAM class>>mmuPageSize (in category 'granularity') ----- + mmuPageSize + ^4096! Item was added: + ----- Method: SharedRAM class>>offsetMask (in category 'granularity') ----- + offsetMask + ^self mmuPageSize - 1! Item was added: + ----- Method: SharedRAM class>>pageMask (in category 'granularity') ----- + pageMask + ^16rFFFFFFFF bitXor: self offsetMask + ! Item was added: + ----- Method: SharedRAM class>>shmOpen:with:with: (in category 'FFI') ----- + shmOpen: name with: oflag with: mode + <cdecl: ulong 'shm_open' (char* ulong ulong) module: '/lib/x86_64-linux-gnu/librt.so.1'> + ^self externalCallFailed + ! Item was added: + ----- Method: SharedRAM>>byteAtAddr:put: (in category 'writing') ----- + byteAtAddr: byteAddress put: byte + | ptr | + byteAddress = 16r109014 ifTrue: [self halt]. + ptr := self translate: byteAddress. + ptr unsignedByteAt: 1 put: byte! Item was added: + ----- Method: SharedRAM>>fillFromStream:startingAt:count: (in category 'writing') ----- + fillFromStream: aFileStream startingAt: startAddress count: count + | contents | + contents := aFileStream next: count. + self writeBytes: contents toAddr: startAddress. + ^contents size! Item was added: + ----- Method: SharedRAM>>forceRead32At: (in category 'address translation') ----- + forceRead32At: addr + | x | + self halt. "I don't remember why this was needed." + x := super read32At: addr. + tlb := self getTLB. + ^x + ! Item was added: + ----- Method: SharedRAM>>forceReadAt:nBytes: (in category 'address translation') ----- + forceReadAt: addr nBytes: n + super readAt: addr nBytes: n. + tlb := self getTLB! Item was added: + ----- Method: SharedRAM>>forceWriteBytes:toAddr: (in category 'address translation') ----- + forceWriteBytes: aByteArray toAddr: addr + | x | + x := super writeBytes: aByteArray toAddr: addr. + tlb := self getTLB. + ^x + ! Item was added: + ----- Method: SharedRAM>>forceWriteInt32:toAddr: (in category 'address translation') ----- + forceWriteInt32: int toAddr: addr + | x | + x := super writeInt32: int toAddr: addr. + tlb := self getTLB. + ^x + ! Item was added: + ----- Method: SharedRAM>>getTLB (in category 'RSP') ----- + getTLB + | answer | + answer := self gdb q: '.'. + answer isEmpty ifTrue: [ self error: 'GDB failed to return TLB' ]. + ^Dictionary newFromAssociations: + (((answer findTokens: ';') + collect: [ :s | s findTokens: ':' ]) + collect: [ :pair | (Integer readFrom: pair first base: 16) -> (Integer readFrom: pair last base: 16) ])! Item was added: + ----- Method: SharedRAM>>hostPtr (in category 'shmem') ----- + hostPtr + hostPtr isNil ifTrue: [ hostPtr := Gem5SharedRAM gem5: shmemSize ]. + ^hostPtr! Item was added: + ----- Method: SharedRAM>>longAtAddr:put:bigEndian: (in category 'writing') ----- + longAtAddr: addr put: aValue bigEndian: bigEndian + | ptr int | + int := bigEndian + ifTrue: [ aValue byteSwap32 ] + ifFalse: [ aValue ]. + ptr := self translate: addr. + ptr unsignedLongAt: 1 put: int + + + + ! Item was added: + ----- Method: SharedRAM>>read:bytesAtAddr: (in category 'reading') ----- + read: n bytesAtAddr: addr + | backingAddr | + backingAddr := self translate: addr. + ^((1 to: n) collect: [ :idx| backingAddr byteAt: idx ]) asByteArray + ! Item was added: + ----- Method: SharedRAM>>shmemSize (in category 'shmem') ----- + shmemSize + ^shmemSize! Item was added: + ----- Method: SharedRAM>>shmemSize: (in category 'shmem') ----- + shmemSize: howBig + shmemSize := howBig! Item was added: + ----- Method: SharedRAM>>translate: (in category 'address translation') ----- + translate: addr + | pageAddr | + pageAddr := self virt2phys: addr. + pageAddr isNil ifTrue: [ ^ self error forceRead32At: addr ]. + ^self hostPtr getHandle + pageAddr. + ! Item was added: + ----- Method: SharedRAM>>unsignedLongAtAddr:bigEndian: (in category 'reading') ----- + unsignedLongAtAddr: addr bigEndian: bigEndian + | backingAddr int | + backingAddr := self translate: addr. + int := backingAddr unsignedLongAt: 1. + bigEndian ifTrue: [ int := int byteSwap32]. + ^int! Item was added: + ----- Method: SharedRAM>>virt2phys: (in category 'address translation') ----- + virt2phys: anAddress + self subclassResponsibility! Item was added: + ----- Method: SharedRAM>>writeBytes:toAddr: (in category 'writing') ----- + writeBytes: aByteArray toAddr: addr + | ptr | + addr = 16r109014 ifTrue: [self halt]. + ptr := self translate: addr. + aByteArray doWithIndex: [ :x :idx | ptr unsignedByteAt: idx put: x ] "is there a faster way?" + ! Item was changed: ----- Method: ShmemDoodle>>connectGdb (in category 'target connection') ----- connectGdb super connectGdb. + memory shmemSize: 16r120000 + (120*1024*1024). "for Squeak" + plainRAM := SimpleSharedRAM gdb: gdb. - memory shmemSize: 536870912. "size of TAM's thinshell process image" - plainRAM := RemoteRAM gdb: gdb. ^gdb! Item was changed: ----- Method: ShmemDoodle>>remoteMemoryClass (in category 'target connection') ----- remoteMemoryClass + ^SimpleSharedRAM! - ^Gem5SharedRAM! Item was changed: ----- Method: ShmemDoodle>>testSharedToNonShared (in category 'tests-agreement') ----- + testSharedToNonShared + self shouldBeImplemented! - testSharedToNonShared! Item was added: + ----- Method: ShmemDoodle>>testSimpleSharedRAM (in category 'tests-agreement') ----- + testSimpleSharedRAM + " + ShmemDoodle new testSimpleSharedRAM. + + " + | rwAddress bytes | + self break. + self connectGdb. + gdb q: 'c'. "cant do real #c because we don't have a pdl with registers" + rwAddress := 16r120000. + "m shmemSize: 16r120000 + (120*1024*1024)." + bytes := memory read: 2 bytesAtAddr: rwAddress. + + memory writeBytes: #[1 2 3 4] toAddr: rwAddress. + + self assert: (memory unsignedLongAtAddr: rwAddress bigEndian: true) equals: 16r01020304. + self assert: (memory unsignedLongAt: rwAddress + 1 bigEndian: true) equals: 16r01020304. + self assert: (memory read: 4 bytesAtAddr: rwAddress) equals: #[1 2 3 4]. + self assert: (memory unsignedByteAtAddr: rwAddress) equals: 1. + self assert: (memory unsignedByteAtAddr: rwAddress+1) equals: 2. + + [ gdb kill ] on: GdbChildExited do: [ ^self ] + ! Item was added: + SharedRAM subclass: #SimpleSharedRAM + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'GDB-RSP'! Item was added: + ----- Method: SimpleSharedRAM>>virt2phys: (in category 'as yet unclassified') ----- + virt2phys: anAddress + ^anAddress - 16r20000! Item was added: + Error subclass: #SimulatedLeafReturn + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: 'GDB-Cog'! Item was added: + ----- Method: SimulationAddressSpace>>bytesPerElement (in category 'as yet unclassified') ----- + bytesPerElement + ^self class bytesPerElement! Item was added: + ----- Method: TargetAwareX86 class>>isHardware (in category 'machine description') ----- + isHardware + "Answer true if we are running on an actual hardware target. + Browse senders to see all places where gem5 differs from silicon." + + ^false! Item was changed: ----- Method: TargetAwareX86 class>>new (in category 'instance creation') ----- new " TargetAwareX86 new " Current := super new connectGdb. ^Current! Item was added: + ----- Method: TargetAwareX86 class>>printTempNames (in category 'class initialization') ----- + printTempNames + ^false! Item was added: + ----- Method: TargetAwareX86 class>>printTempNames: (in category 'class initialization') ----- + printTempNames: x! Item was added: + ----- Method: TargetAwareX86 class>>remoteMemoryClass (in category 'machine description') ----- + remoteMemoryClass + ^self isHardware + ifTrue: [SimpleSharedRAM] + ifFalse: [Gem5SharedRAM]! Item was added: + ----- Method: TargetAwareX86 class>>setReceiverResultReg: (in category 'class initialization') ----- + setReceiverResultReg: x! Item was added: + ----- Method: TargetAwareX86>>accessorIsFramePointerSetter: (in category 'accessing-abstract') ----- + accessorIsFramePointerSetter: accessor + "Answer if accessor is an accessor for the frame pointer. Subclasses that don't call + it fp must override to check for both names." + ^#fp: == accessor or: [#ebp: == accessor]! Item was added: + ----- Method: TargetAwareX86>>bogusRetPC (in category 'entering execution') ----- + bogusRetPC + ^16rBADF00D5! Item was added: + ----- Method: TargetAwareX86>>cResultRegister: (in category 'accessing-abstract') ----- + cResultRegister: aValue + ^self eax: aValue! Item was added: + ----- Method: TargetAwareX86>>cl (in category 'intel registers') ----- + cl + ^self ecx bitAnd: 16rFF! Item was changed: ----- Method: TargetAwareX86>>connectGdb (in category 'target connection') ----- connectGdb gdb := self debuggerClass host: self hostIP port: self tcpPort processorDescription: self pdl. + self runThinshellPrologue. ^self "not gdb; #new needs the instance"! Item was added: + ----- Method: TargetAwareX86>>controlRegisterGetters (in category 'accessing-abstract') ----- + controlRegisterGetters + ^#(eip eflags)! Item was added: + ----- Method: TargetAwareX86>>convertIntegerToInternal: (in category 'tests support') ----- + convertIntegerToInternal: anInteger + "Default conversion for 32-bit processors. 64-bit processors override." + ^anInteger signedIntToLong! Item was added: + ----- Method: TargetAwareX86>>decorateDisassembly:for:fromAddress: (in category 'disassembly') ----- + decorateDisassembly: anInstructionString for: aSymbolManager "<Cogit>" fromAddress: address + ^BochsIA32Alien new + decorateDisassembly: anInstructionString for: aSymbolManager "<Cogit>" fromAddress: address! Item was added: + ----- Method: TargetAwareX86>>disassembleCurrentInstructionIn: (in category 'disassembly') ----- + disassembleCurrentInstructionIn: memory + ^(self primitiveDisassembleAt: self pc inMemory: memory) last! Item was added: + ----- Method: TargetAwareX86>>disassembleFrom:to:in:for:labels:on: (in category 'disassembly') ----- + disassembleFrom: startAddress to: endAddress in: memory for: aSymbolManager "<Cogit>" labels: labelDictionary on: aStream + | prefix theseBytes | + prefix := ByteArray new: startAddress. + theseBytes := (startAddress to: endAddress) collect: [ :addr | memory byteAtAddr: addr ]. + BochsIA32Alien new + disassembleFrom: startAddress + to: endAddress + in: prefix, theseBytes + for: aSymbolManager "<Cogit>" + labels: labelDictionary on: aStream + ! Item was added: + ----- Method: TargetAwareX86>>disassembleInstructionAt:In: (in category 'disassembly') ----- + disassembleInstructionAt: pc In: memory + ^(self primitiveDisassembleAt: pc inMemory: memory) last! Item was added: + ----- Method: TargetAwareX86>>eflags (in category 'intel registers') ----- + eflags + ^gdb getRegister: 'eflags'! Item was added: + ----- Method: TargetAwareX86>>floatingPointRegisterStateGetters (in category 'accessing-abstract') ----- + floatingPointRegisterStateGetters + ^#()! Item was added: + ----- Method: TargetAwareX86>>handleDataFailureIn: (in category 'execution') ----- + handleDataFailureIn: memoryArray + | pc opcode | + pc := self eip. + opcode := memoryArray byteAt: pc + 1. + opcode ~= 16r0f ifTrue: + [^self + perform: (OpcodeExceptionMap at: opcode + 1) + with: pc + with: memoryArray]. + opcode := memoryArray byteAt: pc + 2. + ^self + perform: (ExtendedOpcodeExceptionMap at: opcode + 1) + with: pc + with: memoryArray! Item was changed: ----- Method: TargetAwareX86>>handleExecutionPrimitiveFailureIn:minimumAddress: (in category 'execution') ----- handleExecutionPrimitiveFailureIn: memoryArray minimumAddress: minimumAddress + "Execution stopped due to SIGSEGV. + Convert out-of-range call and absolute memory read-into-register instructions + into ProcessorSimulationTrap signals." + + "The SEGV could be caused by Fetching from an unmapped address, + or a data operation with an unmapped address. + While a simulator such as gem5 could tell us what caused the fault, + real hardware such as silicon i386 doesn't provide an easy way; + therefore, we have to look at circumstancial evidence." + (self isWithinMappedRange: self eip) + ifTrue: [ ^self handleDataFailureIn: memoryArray ] + ifFalse: [ ^self handlePcOutOfRangeIn: memoryArray ]! - "NB: THIS SHOULD GO INTO A COMMON SemihostABI CLASS -- bgs" - "Handle an execution primitive failure. Convert out-of-range call and absolute - memory read into register instructions into ProcessorSimulationTrap signals." - "self printIntegerRegistersOn: Transcript" - "self printRegistersOn: Transcript" - | pc opcode | - pc := self eip. - " (() between: minimumAddress and: memoryArray byteSize - 1) ifTrue: self reportPrimitiveFailure -- TODO" - opcode := memoryArray byteAt: pc + 1. - opcode ~= 16r0f ifTrue: - [^self - perform: (OpcodeExceptionMap at: opcode + 1) - with: pc - with: memoryArray]. - opcode := memoryArray byteAt: pc + 2. - ^self - perform: (ExtendedOpcodeExceptionMap at: opcode + 1) - with: pc - with: memoryArray! Item was added: + ----- Method: TargetAwareX86>>handlePcOutOfRangeIn: (in category 'execution') ----- + handlePcOutOfRangeIn: memoryArray + | pc | + pc := self pc. + pc = self bogusRetPC ifTrue: [ ^self cResultRegister ]. + ^(ProcessorSimulationTrap + pc: nil + nextpc: nil + address: pc + type: #controlTransfer) + signal! Item was added: + ----- Method: TargetAwareX86>>initializeStackFor: (in category 'processor setup') ----- + initializeStackFor: aCogit + "Different cpus need different stack alignment etc, so handle the details here." + "This is for testing. On many OS's the stack must remain aligned; + e.g. IA32 using SSE requires 16 byte alignment." + | stackAlignment | + stackAlignment := 16. + aCogit setStackAlignment: stackAlignment expectedSPOffset: 0 expectedFPOffset: 8. + PostBuildStackDelta := stackAlignment > 8 + ifTrue: [stackAlignment - 8] + ifFalse: [0]! Item was added: + ----- Method: TargetAwareX86>>isWithinMappedRange: (in category 'execution') ----- + isWithinMappedRange: anAddress + | minimumAddress maximumAddress | + minimumAddress := 4096. + maximumAddress := 120*1024*1024 - 1. + ^anAddress >= minimumAddress and: [ anAddress <= maximumAddress ]! Item was added: + ----- Method: TargetAwareX86>>leafRetpcIn: (in category 'accessing-abstract') ----- + leafRetpcIn: aMemory + ^aMemory unsignedLongAt: self esp + 1 bigEndian: false! Item was added: + ----- Method: TargetAwareX86>>popWordIn: (in category 'execution') ----- + popWordIn: aMemory + | sp word | + word := aMemory unsignedLongAt: (sp := self esp) + 1 bigEndian: false. + self esp: sp + 4. + ^word! Item was added: + ----- Method: TargetAwareX86>>postCallArgumentsNumArgs:in: (in category 'execution') ----- + postCallArgumentsNumArgs: numArgs "<Integer>" in: memory "<ByteArray|Bitmap>" + "Answer an argument vector of the requested size after a vanilla + ABI call. On IA32 this typically means accessing stacked arguments + beyond the pushed return address and saved frame pointer. + For compatibility with Cog/Slang we answer unsigned values." + ^(9 to: numArgs * 4 + 5 by: 4) collect: + [:i| + memory unsignedLongAt: self ebp + i bigEndian: false]! Item was added: + ----- Method: TargetAwareX86>>primitiveDisassembleAt:inMemory: (in category 'disassembly') ----- + primitiveDisassembleAt: address inMemory: memory + | prefix theseBytes | + prefix := ByteArray new: address. + theseBytes := (address to: address + 16) collect: [ :addr | memory byteAtAddr: addr ]. + ^BochsIA32Alien new + primitiveDisassembleAt: address inMemory: prefix, theseBytes! Item was added: + ----- Method: TargetAwareX86>>printNameOn: (in category 'printing') ----- + printNameOn: aStream + super printOn: aStream! Item was added: + ----- Method: TargetAwareX86>>registerStateGetters (in category 'accessing-abstract') ----- + registerStateGetters + ^#( eax ecx edx ebx esp ebp esi edi eip eflags )! Item was removed: - ----- Method: TargetAwareX86>>remoteMemoryClass (in category 'target connection') ----- - remoteMemoryClass - ^Gem5SharedRAM! Item was added: + ----- Method: TargetAwareX86>>reportPrimitiveFailure (in category 'error handling') ----- + reportPrimitiveFailure + self shouldBeImplemented! Item was added: + ----- Method: TargetAwareX86>>retpcIn: (in category 'accessing-abstract') ----- + retpcIn: aMemory + ^aMemory unsignedLongAt: self ebp + 5 bigEndian: false! Item was added: + ----- Method: TargetAwareX86>>runInMemory:minimumAddress: (in category 'execution') ----- + runInMemory: aMemory minimumAddress: minimumAddress + | stopReason | + stopReason := gdb c. + stopReason signal = #SIGSEGV ifTrue: [ + ^self + handleExecutionPrimitiveFailureIn: aMemory + minimumAddress: minimumAddress ]. + stopReason signal = #SIGQUIT ifTrue: [ ^self halt ]. + + "There can be a number of other reasons to stop. + For example, a debug breakpoint." + self shouldBeImplemented! Item was changed: ----- Method: TargetAwareX86>>runInMemory:minimumAddress:readOnlyBelow: (in category 'execution') ----- runInMemory: aMemory minimumAddress: minimumAddress readOnlyBelow: minimumWritableAddress + ^self runInMemory: aMemory minimumAddress: minimumAddress! - | stopReason | - stopReason := gdb c. - stopReason signal = #SIGSEGV ifFalse: [ self shouldBeImplemented ]. - ^self - handleExecutionPrimitiveFailureIn: aMemory - minimumAddress: minimumAddress! Item was added: + ----- Method: TargetAwareX86>>runThinshellPrologue (in category 'target connection') ----- + runThinshellPrologue + "Run the thinshell's _start to do whatever initialization it needs, + until it stops (usually indicates 'I am done' by segfaulting or trapping)" + gdb c! Item was added: + ----- Method: TargetAwareX86>>simulateBuildFrameIn:for: (in category 'execution') ----- + simulateBuildFrameIn: aMemory for: evaluable + "Simulate a frame-building call of address. Build a frame since + a) this is used for calls into the run-time which are unlikely to be leaf-calls, and + b) stack alignment needs to be realistic for assert checking for platforms such as Mac OS X" + | sp | + sp := self esp. + self pushWord: sp in: aMemory. + sp := sp - 4. + self ebp: sp. + PostBuildStackDelta ~= 0 ifTrue: + [self esp: sp - PostBuildStackDelta]. + ! Item was added: + ----- Method: TargetAwareX86>>simulateCallIn: (in category 'execution') ----- + simulateCallIn: aMemory + "The return address has already been pushed." + self pushWord: self ebp in: aMemory. + self ebp: self esp. + PostBuildStackDelta ~= 0 ifTrue: + [self esp: self esp - PostBuildStackDelta].! Item was added: + ----- Method: TargetAwareX86>>simulateCallOf: (in category 'execution') ----- + simulateCallOf: anAddress + self shouldBeImplemented! Item was added: + ----- Method: TargetAwareX86>>simulateCallOf:nextpc:memory: (in category 'execution') ----- + simulateCallOf: address nextpc: nextpc memory: aMemory + "Simulate a frame-building call of address. Build a frame since + a) this is used for calls into the run-time which are unlikely to be leaf-calls, and + b) stack alignment needs to be realistic for assert checking for platforms such as Mac OS X" + self pushWord: nextpc in: aMemory. + self pushWord: self ebp in: aMemory. + self ebp: self esp. + PostBuildStackDelta ~= 0 ifTrue: + [self esp: self esp - PostBuildStackDelta]. + self eip: address! Item was added: + ----- Method: TargetAwareX86>>simulateJumpCallOf:memory: (in category 'execution') ----- + simulateJumpCallOf: address memory: aMemory + "Simulate a frame-building jump call of address (i.e. do not push the return pc + as this has already been done). Build a frame since + a) this is used for calls into the run-time which are unlikely to be leaf-calls, and + b) stack alignment needs to be realistic for assert checking for platforms such as Mac OS X" + self pushWord: self ebp in: aMemory. + self ebp: self esp. + PostBuildStackDelta ~= 0 ifTrue: + [self esp: self esp - PostBuildStackDelta]. + self eip: address! Item was added: + ----- Method: TargetAwareX86>>simulateLeafCallOf:for: (in category 'entering execution') ----- + simulateLeafCallOf: someFunction for: aCogit + "Natively execute the CPU code for someFunction until it returns. + Answer the contents of the C ABI return register, an Integer." + | priorSP priorPC spOnEntry | + priorSP := self sp. + priorPC := self pc. + self + setFramePointer: aCogit coInterpreter getCFramePointer stackPointer: aCogit coInterpreter getCStackPointer; + simulateLeafCallOf: someFunction + nextpc: self bogusRetPC + memory: aCogit objectMemory memory. + spOnEntry := self sp. + aCogit singleStep + ifTrue: [ self shouldBeImplemented ]. + [true] whileTrue: [ + [ self runInMemory: aCogit objectMemory memory minimumAddress: 4096 ] + on: SimulatedLeafReturn + do: [ ^self cResultRegister ] ]! Item was added: + ----- Method: TargetAwareX86>>simulateReturnIn: (in category 'execution') ----- + simulateReturnIn: aMemory + PostBuildStackDelta ~= 0 ifTrue: + [self esp: self esp + PostBuildStackDelta]. + self ebp: (self popWordIn: aMemory). + self eip: (self popWordIn: aMemory)! Item was added: + ----- Method: TargetAwareX86>>simulateTearFrameIn: (in category 'execution') ----- + simulateTearFrameIn: aMemory + "Simulate a frame-building call of address. Build a frame since + a) this is used for calls into the run-time which are unlikely to be leaf-calls, and + b) stack alignment needs to be realistic for assert checking for platforms such as Mac OS X" + + PostBuildStackDelta ~= 0 ifTrue: + [self esp: self esp + PostBuildStackDelta]. + self esp: (self popWordIn: aMemory).! Item was added: + ----- Method: TargetAwareX86>>smashCallerSavedRegistersWithValuesFrom:by:in: (in category 'execution') ----- + smashCallerSavedRegistersWithValuesFrom: base by: step in: aMemory + #(eax: ecx: edx:) + withIndexDo: + [:accessor :index| + self perform: accessor with: index - 1 * step + base]!

1 0

VM Maker: VMMaker.gdb-bgs.2747.mcz
by commits＠source.squeak.org 26 May '20

26 May '20

Boris G. Shingarov uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.gdb-bgs.2747.mcz ==================== Summary ==================== Name: VMMaker.gdb-bgs.2747 Author: bgs Time: 26 May 2020, 5:20:53.475745 pm UUID: df2f1386-35b8-4e3c-b848-2fe2764ad3df Ancestors: VMMaker.gdb-bgs.2746 Execution on non-simulated hardware. Corresponds to GDB.bgs-2. =============== Diff against VMMaker.gdb-bgs.2746 =============== Item was changed: ----- Method: CogVMSimulator>>moveMethodCacheToMemoryAt: (in category 'initialization') ----- moveMethodCacheToMemoryAt: address | oldMethodCache | oldMethodCache := methodCache. "In the VM the methodCache is written as a normal array with 1-relative addressing. In C this works by allocating an extra element in the methodCache array (see class-side declareCVarsIn:). In simulation simply position the start of the methodCache one word lower, achieving the same effect. -1 because CArrayAccessor is 0-relative and adds 1 on accesses itself." methodCache := CMethodCacheAccessor new objectMemory: objectMemory at: address array: oldMethodCache functionPointerIndex: MethodCachePrimFunction entrySize: MethodCacheEntrySize. self assert: address - objectMemory wordSize = self methodCacheAddress. + " 1 to: MethodCacheSize do: - 1 to: MethodCacheSize do: [:i| + self assert: (methodCache at: i) = 0]. " - self assert: (methodCache at: i) = 0]. methodCache at: 1 put: 16rC4EC4. self assert: (objectMemory longAt: address) = 16rC4EC4. 1 to: MethodCacheSize do: [:i| methodCache at: i put: (oldMethodCache at: i)]! Item was changed: ----- Method: CogVMSimulator>>movePrimTraceLogToMemoryAt: (in category 'initialization') ----- movePrimTraceLogToMemoryAt: address | oldTraceLog | oldTraceLog := primTraceLog. primTraceLog := CArrayOfLongsAccessor new objectMemory: objectMemory at: address. self assert: address = self primTraceLogAddress. + " 0 to: PrimTraceLogSize - 1 do: - 0 to: PrimTraceLogSize - 1 do: [:i| + self assert: (primTraceLog at: i) = 0]." - self assert: (primTraceLog at: i) = 0]. primTraceLog at: 0 put: 16rC4EC4. self assert: (objectMemory longAt: address) = 16rC4EC4. 0 to: PrimTraceLogSize - 1 do: [:i| primTraceLog at: i put: (oldTraceLog at: i)]! Item was changed: ----- Method: Cogit>>simulateLeafCallOf: (in category 'simulation only') ----- simulateLeafCallOf: someFunction "Simulate execution of machine code that leaf-calls someFunction, answering the result returned by someFunction." "CogProcessorAlienInspector openFor: coInterpreter" <doNotGenerate> | priorSP priorPC priorLR spOnEntry bogusRetPC | + self recordRegisters. priorSP := processor sp. priorPC := processor pc. priorLR := backEnd hasLinkRegister ifTrue: [processor lr]. processor setFramePointer: coInterpreter getCFramePointer stackPointer: coInterpreter getCStackPointer; simulateLeafCallOf: someFunction nextpc: (bogusRetPC := 16rBADF00D5 roundTo: backEnd codeGranularity) memory: coInterpreter memory. spOnEntry := processor sp. self recordInstruction: {'(simulated call of '. someFunction. ')'}. [[processor pc between: 0 and: methodZone zoneEnd] whileTrue: [[singleStep ifTrue: [ self recordProcessing. self maybeBreakAt: processor pc. processor singleStepIn: coInterpreter memory minimumAddress: guardPageSize readOnlyBelow: methodZone zoneEnd] ifFalse: [processor runInMemory: coInterpreter memory minimumAddress: guardPageSize readOnlyBelow: methodZone zoneEnd]] on: ProcessorSimulationTrap, Error do: [:ex| | retpc | processor pc = bogusRetPC ifTrue: [self recordInstruction: {'(simulated (real) return to '. processor pc. ')'}. ^processor cResultRegister]. ex class == ProcessorSimulationTrap ifTrue: [ex type == #read ifTrue: [self handleReadSimulationTrap: ex. ex resume: processor]. ex type == #write ifTrue: [self handleWriteSimulationTrap: ex. ex resume: processor]. ex type == #return ifTrue: [retpc := processor leafRetpcIn: coInterpreter memory. self assert: retpc = bogusRetPC. processor simulateLeafReturnIn: coInterpreter memory. self recordInstruction: {'(simulated return to '. retpc. ')'}. ^processor cResultRegister]]. ex pass]]. processor pc = bogusRetPC ifTrue: [self recordInstruction: {'(simulated (real) return to '. processor pc. ')'}]. ^processor cResultRegister] ensure: [processor sp: priorSP. processor pc: priorPC. priorLR ifNotNil: [:lr| processor lr: lr]]! Item was changed: ----- Method: Spur32BitMemoryManager>>memoryClass (in category 'simulation') ----- memoryClass <doNotGenerate> + ^TargetAwareX86 remoteMemoryClass - | choices | - choices := #(LittleEndianBitmap Gem5SharedRAM). - ^Smalltalk at: (choices at: (UIManager default chooseFrom: choices)). "^self endianness == #little ifTrue: [LittleEndianBitmap] ifFalse: [Bitmap]" !

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2020