[Scummvm-devel] ida dosbox plugin (Pawel Kolodziejski)

Robert Megone silver_coast at hotmail.com
Thu Apr 9 11:29:27 CEST 2009


This looks quite promising.

Robert Megone




> From: scummvm-devel-request at lists.sourceforge.net
> Subject: Scummvm-devel Digest, Vol 35, Issue 5
> To: scummvm-devel at lists.sourceforge.net
> Date: Thu, 9 Apr 2009 08:04:28 +0000
> 
> Send Scummvm-devel mailing list submissions to
> 	scummvm-devel at lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/scummvm-devel
> or, via email, send a message with subject or body 'help' to
> 	scummvm-devel-request at lists.sourceforge.net
> 
> You can reach the person managing the list at
> 	scummvm-devel-owner at lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scummvm-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Fwd:  PS2 : stack madness (sunmax at libero.it)
>    2. Re: Fwd:  PS2 : stack madness (Willem Jan Palenstijn)
>    3. Re: Fwd:  PS2 : stack madness (sunmax at libero.it)
>    4. Re: Fwd:  PS2 : stack madness (Willem Jan Palenstijn)
>    5. Re: Fwd:  PS2 : stack madness (sunmax at libero.it)
>    6. Re: Fwd:  PS2 : stack madness (Willem Jan Palenstijn)
>    7. ida dosbox plugin (Pawel Kolodziejski)
>    8. Re: SCI: _k_disable_delete_for_now () (lskovlun at image.dk)
>    9. Re: Cruise for a Corpse music handling (Gregory Montoir)
>   10. Re: Cruise for a Corpse music handling (Paul Gilbert)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue,  7 Apr 2009 22:48:52 +0200
> From: "sunmax\@libero\.it" <sunmax at libero.it>
> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness
> To: "bertrand_augereau" <bertrand_augereau at yahoo.fr>
> Cc: max <max at quendi.de>, scummvm-devel
> 	<scummvm-devel at lists.sourceforge.net>
> Message-ID: <KHR0HG$EF4C4003CC6567D1549A3124B56E46D5 at libero.it>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Hi there!
> 
> > Is there a big stack allocation somewhere related?
> 
> This is one of my possible culprits too - to see if something
> in-between 0.12.x to 0.13.0 went stack-on-steroids.
> 
> Any idea?
> 
> 
> > For instance a templated stack array or a malloca for storing
> > a few temporary lines or something?
> 
> In MADE moving few stack items to heap made it PS2-friendly
> (well, kinda: I have to find a way to improve performance on
> our beloved console!).
> 
> On the other hand we want to be careful, cause I am afraid
> that doing this (I mean: moving the possible out of the stack)
> we could be just dancing around the bug, instead of squeezing it.
> 
> Thanks!
>  -max
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 7 Apr 2009 21:08:01 +0000
> From: Willem Jan Palenstijn <wjp at usecode.org>
> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness
> To: "sunmax at libero.it" <sunmax at libero.it>
> Cc: max <max at quendi.de>, scummvm-devel
> 	<scummvm-devel at lists.sourceforge.net>
> Message-ID: <20090407210801.GA30052 at usecode.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Apr 07, 2009 at 10:48:52PM +0200, sunmax at libero.it wrote:
> > Hi there!
> > 
> > > Is there a big stack allocation somewhere related?
> > 
> > This is one of my possible culprits too - to see if something
> > in-between 0.12.x to 0.13.0 went stack-on-steroids.
> > 
> > Any idea?
> 
> I see no large stack allocations when starting COMI and opening the F5 and
> Ctrl-F5 menus.
> 
> (Testing method: I told valgrind to make a large block of memory 1024
> bytes below the stack pointer at the start of scummvm_main inaccessible.
> This triggered no errors. I'm using 64 bit linux.)
> 
> 
> -Willem Jan
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue,  7 Apr 2009 23:17:38 +0200
> From: "sunmax\@libero\.it" <sunmax at libero.it>
> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness
> To: "wjp" <wjp at usecode.org>
> Cc: scummvm-devel <scummvm-devel at lists.sourceforge.net>
> Message-ID: <KHR1TE$907D37C9B5C0034B4D4C0B80A56BEC74 at libero.it>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Hi Willem!
> 
> Thanks for following up!
> 
> > I see no large stack allocations when starting COMI
> 
> Note that "big" in PS2 world is a signed word: 32 Kb ;-)
> 
> 
> > and opening the F5 and Ctrl-F5 menus.
> 
> Sorry about this! That's was the first version of the report,
> it actually happens independently from calling the GMM.
> 
> It's likely somewhere in GuiManager::runLoop or just a bit earlier.
> 
> Which scaler are you using?
> 
> Thanks!
>  -max
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 7 Apr 2009 21:38:35 +0000
> From: Willem Jan Palenstijn <wjp at usecode.org>
> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness
> To: "sunmax at libero.it" <sunmax at libero.it>
> Cc: scummvm-devel <scummvm-devel at lists.sourceforge.net>
> Message-ID: <20090407213835.GB30052 at usecode.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Apr 07, 2009 at 11:17:38PM +0200, sunmax at libero.it wrote:
> > Which scaler are you using?
> 
> No scaler, just running in native 640x480. It behaves the same with
> '-g 2x', though.
> 
> 
> I noticed in another mail that you found a place where SP was bogus. Did
> you try putting lots of printfs of the stack pointer (or of a local
> stack variable) just before that? That might help pin down the exact
> code that corrupts the stack. As Max (Horn) mentioned, this could be
> done indirectly by a return from a function call.
> 
> That would really help, since it's very hard to analyze bugs like this
> without run-time information.
> 
> 
> Did you already track down what caused the menu to be placed near the
> upper-left corner instead of in the center, by the way? (The issue you
> illustrated with a photo on March 8.) Maybe that would give a clue
> too...
> 
> -Willem Jan
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed,  8 Apr 2009 05:59:09 +0200
> From: "sunmax\@libero\.it" <sunmax at libero.it>
> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness
> To: "wjp" <wjp at usecode.org>
> Cc: scummvm-devel <scummvm-devel at lists.sourceforge.net>
> Message-ID: <KHRKEL$335957A1F7C768C8C1455E51DA5DA546 at libero.it>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Hi there Willem!
> 
> > > Which scaler are you using?
> > 
> > No scaler, just running in native 640x480.
> 
> Got it.
> 
> Is there any way you can start your GUI 320x200 and then let
> the Scumm engine to crank it up to 640x480 before starting
> COMI and see if this makes a difference?
> 
> 
> > I noticed in another mail that you found a place where SP was bogus
> 
> Yes.
> 
> As in most of stack related issues, just moving functions or adding
> new ones can cause the crash to move. The good things of our crash
> is that's predictable:
> 
> given a certain code base and compiler settings it will always
> crash at the same point. On the other hand when we keep adding
> new variables on the stack and more printf, we "lose" it:
> it starts crashing somewhere else :-(
> 
> Obviously the point where it crashes is not the cause but just
> a "side effect" of the real bug.
> 
> 
> > you try putting lots of printfs of the stack pointer (or of a local
> > stack variable) just before that?
> 
> I was able to trace it back up to guiManager::runLoop but then I
> "lose" it from there - having gdb would definitely make a diff ;-)
> 
> It only happens with 640x480 (but that could be a red herring).
> 
> 
> > Did you already track down what caused the menu to be placed near
> > the upper-left corner instead of in the center, by the way?
> 
> No, but I am sure they are related. It seems the GUI engine still
> "thinks" the screens is 320x200 and paints in the corresponding
> corner, that's why I was asking to see if you can start 320x200
> and then when you start COMI see if things make a difference
> going up to 640x480 on the fly.
> 
> Thanks for the great support guys!
>  -max
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 8 Apr 2009 08:22:31 +0000
> From: Willem Jan Palenstijn <wjp at usecode.org>
> Subject: Re: [Scummvm-devel] Fwd:  PS2 : stack madness
> To: "sunmax at libero.it" <sunmax at libero.it>
> Cc: scummvm-devel <scummvm-devel at lists.sourceforge.net>
> Message-ID: <20090408082231.GC30052 at usecode.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Wed, Apr 08, 2009 at 05:59:09AM +0200, sunmax at libero.it wrote:
> > Is there any way you can start your GUI 320x200 and then let
> > the Scumm engine to crank it up to 640x480 before starting
> > COMI and see if this makes a difference?
> 
> Running scummvm with '-g 1x' (so that it runs in 320x200) and then
> starting COMI from the launcher shows nothing strange, and no large
> stack increase either.
> 
> 
> > given a certain code base and compiler settings it will always
> > crash at the same point. On the other hand when we keep adding
> > new variables on the stack and more printf, we "lose" it:
> > it starts crashing somewhere else :-(
> 
> That itself might also give a clue. This is a bit of a longshot, but it
> might work:
> 
> 
> Take the function where adding printfs makes you "lose" the crash.
> 
> At the very beginning of that function, add some code:
> 
> int canary[64];
> for (int ci=0; ci<64; ++ci) canary[i] = 0x12345678;
> 
> Then after every function call in that function (and maybe in other
> places too), put a check:
> 
> for (int ci=0; ci<64; ++ci) assert(canary[i] == 0x12345678);
> 
> 
> If it shows that a specific function call corrupted the canary-variable,
> you can then repeat this procedure inside that function. That _might_
> give enough info to find the guilty code.
> 
> 
> 
> One other option: does your gcc support the option -fstack-protector-all ?
> 
> 
> 
> -Willem Jan
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 8 Apr 2009 17:16:24 +0200
> From: Pawel Kolodziejski <aquadran at xtr.net.pl>
> Subject: [Scummvm-devel] ida dosbox plugin
> To: scummvm-devel <scummvm-devel at lists.sourceforge.net>
> Message-ID: <2F434436-EAFD-4326-B980-E5F830EA48B5 at xtr.net.pl>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> 
> Hi everyone,
> 
> I found today interested info about released ida pro plugin for  
> dosbox :)
> 
> http://efry.users.sourceforge.net/idados/
> and info from:
> http://www.hex-rays.com/forum/viewtopic.php?f=8&t=2286
> 
> Pawel
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Wed, 8 Apr 2009 18:41:02 +0200 (CEST)
> From: lskovlun at image.dk
> Subject: Re: [Scummvm-devel] SCI: _k_disable_delete_for_now ()
> To: "Max Horn" <max at quendi.de>
> Cc: scummvm-devel at lists.sourceforge.net, Lars Skovlund
> 	<lskovlun at image.dk>
> Message-ID:
> 	<49902.80.164.116.14.1239208862.squirrel at webmail.tiscali.dk>
> Content-Type: text/plain;charset=iso-8859-1
> 
> > That was me. (The SVN "annotate" feature is a great way to find out
> > who added a certain piece of code:
> > <http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/engines/sci/engine/kgraphics.cpp?view=annotate
> >  >).
> 
> I thought it was you, actually.
> 
> > Yeah, well, from what you wrote, that's actually exactly what I would
> > call a "workaround" for buggy or bad behavior in the original game
> > resp. engine... ;-). Anyway, the comment was really referring to the
> > "if()" block it preceded, but having looked closer now, I think the
> > whole function deserves a good explanatory comment :-). I guess we can
> > just copy the text of your email for that.
> 
> Can't argue with that.
> 
> >> It sounds like we could intercept file opens of *SG.DIR and
> >> construct an
> >> appropriate file on-the-fly. Similarly we could intercept truncates of
> >> SCI-style savegame files to actually delete the appropriate savegame.
> >> Would this work?
> >
> > It would be possible to do what you describe, I think. Whether it
> > would work... Lars? :) Or, well, let's just try it. I'll take a look
> > at this one day, but you folks shouldn't wait for me, I am not going
> > to do much before my PhD defense in less than two weeks ;).
> 
> As stated elsewhere, we are already doing something like it - but without
> the interception of calls.
> This solution would certainly be compatible with "most" games, but then
> again, we are already compatible with "most" games.
> 
> > I don't see any reason right now to replace the save/load UI of
> > FreeSCI, and that's not "the plan" as far as I am concerned.
> 
> OK.
> 
> > the ability to quit
> 
> Possible.
> 
> > return to the launcher
> 
> Possible.
> 
> >  access the about dialog (with credits)
> 
> Heuristically possible (we know what the menus contain, and they are
> fairly consistent with the leftmost "Sierra logo" menu containing about
> and help; could be messy for non-english versions)
> 
> , and in the future, help dialogs. Well,
> > and load & save dialogs if the engine supports this.
> 
> I don't think we can guarantee that for all games. For some, we can.
> 
> > (Another very nice AEF is the ability to load savestates from the
> > command line. Very handy when debugging stuff.)
> 
> We already had this in FreeSCI, so this is certainly possible.
> 
> > Aha? Well, can't comment, don't know that game at all... If there are
> > issues, I hope they'll eventually be logged and then addressed :)
> 
> This is Walter's domain.
> 
> Lars
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Wed, 08 Apr 2009 23:40:58 +0200
> From: Gregory Montoir <cyx at users.sourceforge.net>
> Subject: Re: [Scummvm-devel] Cruise for a Corpse music handling
> To: scummvm-devel at lists.sourceforge.net
> Message-ID: <49DD19EA.2030100 at users.sourceforge.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> 
> Hi,
> 
> > Just yesterday I committed the beginnings of music support for Cruise 
> > for a Corpse (Cruise engine). As many of you will now, music handling is 
> > one area in particular that I'm not very familiar with, so I'm hoping 
> > that someone else will be able to complete support on top of the basics 
> > I've already added. At the moment, I've implemented a skeleton 
> > MusicPlayer class which loads the raw data associated with a given song, 
> > and set in place calls to it from the appropriate library routines.
> > 
> > Hopefully someone more familiar with the common music structures will be 
> > able to recognise what kind of encoding it's using, and be able to 
> > complete the implementation.
> 
> operation stealth and cruise use a very similar (if not the same) sound 
> code ; soundfx modules with custom pcspeaker/adlib/roland instruments. 
> So looking at cine/sound.cpp may be a good starting point.
> 
> Hope this helps.
> Gregory
> 
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Thu, 9 Apr 2009 18:04:25 +1000
> From: Paul Gilbert <paulfgilbert at gmail.com>
> Subject: Re: [Scummvm-devel] Cruise for a Corpse music handling
> To: ScummVM devel <scummvm-devel at lists.sourceforge.net>
> Message-ID:
> 	<a3b832620904090104k65c98e2do3165b19416d876b at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Thu, Apr 9, 2009 at 7:40 AM, Gregory Montoir
> <cyx at users.sourceforge.net>wrote:
> 
> >
> > operation stealth and cruise use a very similar (if not the same) sound
> > code ; soundfx modules with custom pcspeaker/adlib/roland instruments.
> > So looking at cine/sound.cpp may be a good starting point.
> >
> > Hope this helps.
> > Gregory
> >
> 
> Thanks for the tip - it certainly will simplify things if I can just re-use
> code already written for ScummVM. I'll have a look into it.
> 
> Paul.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> 
> ------------------------------
> 
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
> 
> 
> End of Scummvm-devel Digest, Vol 35, Issue 5
> ********************************************

_________________________________________________________________
View your Twitter and Flickr updates from one place – Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090409/3aef72e8/attachment.html>


More information about the Scummvm-devel mailing list