I think the point of frustration for most people is that I think most people agree on the idea that when you do / discover something for yourself, you learn better than when you simply ask a question and get an answer. Also, this is a debugging mailing list. Nothing to do with Edit and Continue. Edit and Continue questsions would best be asked on a compiler / linker mailing list.
Regarding my first point though, many of the things that you ask are very easy to discover on your own. This is no exception. It seems quite easy to figure out why the stack bytes are reserved for Edit and Continue (thinking about it for about 5 seconds I actually have a very good guess, but I’d be doing you an injustice by not letting you discover it on your own). So instead of posting about all these questions which are not related to Windbg, figure them out. Many of us might be curious to know what you found out, but we’re not too interested in answering questions that are not specifically related to the operation and use of Windbg.
So, that being said, create a test that will allow you to figure out what those extra bytes of stack space are for. How to create such a test? Enable Edit and Continue, then edit something, then continue, then look at the new byets of stack space. What happened?
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Lin George [xxxxx@yahoo.com]
Sent: Monday, August 18, 2008 7:47 AM
To: Kernel Debugging Interest List
Cc: Kernel Debugging Interest List
Subject: Re: [windbg] strange 4 assembly instructions for a function
Sorry for any inconveniences, Martin. Even if no result could be found because of a non-open system, I appreciate the process of discussion which I also learn a lot from each other. 
regards,
George
----- Original Message ----
From: Martin O’Brien
To: Kernel Debugging Interest List
Sent: Monday, August 18, 2008 8:33:38 PM
Subject: Re:[windbg] strange 4 assembly instructions for a function
George, why are you asking us? I don’t know why some on sysinternals didn’t write the document you want. Either way, it is what it
is, man. You’ve just got to let this one go. I hear you on curiosity, but no matter how many different ways and how many time you
ask this question - we do not appear to know the answer, at least at the moment.
mm
Lin George wrote:
> You are so humourous Jim. I am still confused why I can not find any
> materials regarding to this topic. For any other internally topics, like
> linker/compiler optimization, there are abundant documents on System
> Internals.
>
> regards,
> George
>
> ----- Original Message ----
> From: Jim Donelson
> To: Lin George
> Sent: Friday, August 15, 2008 9:24:26 PM
> Subject: Re: [windbg] strange 4 assembly instructions for a function
>
> Yes, get hired by the Microsoft VS Team and look at the source code.
>
>
> On Fri, Aug 15, 2008 at 9:11 AM, Lin George > mailto:xxxxx> wrote:
>
> Thanks Jim,
> Basically I agree with you. I just want to get some referred
> documents about how edit and continue works on the basis of
> reserving more stack space. Do you have any recommendations?
> regards,
> George
>
>
> ----- Original Message ----
> From: Jim Donelson >
> To: Kernel Debugging Interest List > mailto:xxxxx>
> Sent: Friday, August 15, 2008 8:49:13 PM
> Subject: Re: [windbg] strange 4 assembly instructions for a function
>
> Well, this is a kernel list, so none of ever ever use edit and continue.
> I personally never use it as for one thing it does not always work,
> for the reason you stated,and over the years there have been various
> bugs with it.
> Not to mention the fact it causes odd code to be generated.
> Best advice - shut it off.
>
> On Fri, Aug 15, 2008 at 8:46 AM, Jim Donelson > mailto:xxxxx> wrote:
> > Well, this is a kernel list, so none of ever ever use edit and
> continue.
> > I personally never use it as for one thing it does not always work,
> > for the reason you stated,and over the years there have been various
> > bugs with it.
> > Not to mention the fact it causes odd code to be generated.
> > Best advice - shut it off.
> >
> >
> > On Fri, Aug 15, 2008 at 3:02 AM, Lin George
> > wrote:
> >> Thanks Martin,
> >> I agree with you. One more question, why reserving more space
> will enable the edit and continue feature as mentioned? This point I
> am very interested, but can not find any materials through Google
> search. Do you have any more documents in details? Or you describe
> by yourself?
> >> (my confusion is, the developer could edit and insert as much as
> information – like code and data change – as he can, how could we
> predict the space which developer will be used in edit and continue
> feature?)
> >> regards,
> >> George
> >>
> >>
> >> ----- Original Message ----
> >> From: Martin O’Brien > mailto:xxxxx>
> >> To: Kernel Debugging Interest List > mailto:xxxxx>
> >> Sent: Thursday, August 14, 2008 2:52:30 PM
> >> Subject: Re:[windbg] strange 4 assembly instructions for a function
> >>
> >> We seem to be going around in circles, so let’s try this
> differently:
> >>
> >> 1. What is your question? Please include ALL the code relevant
> to it.
> >>
> >> My guess is that your question is:
> >>
> >>> Don’t you think it initializes more stack space than actually
> needed?
> >>
> >> And that this is the code:
> >>
> >>>> 00BA13C0 push ebp
> >>>> 00BA13C1 mov ebp,esp
> >>>> 00BA13C3 sub esp,0C0h
> >>>> 00BA13C9 push ebx
> >>>> 00BA13CA push esi
> >>>> 00BA13CB push edi
> >>>> 00BA13CC lea edi,[ebp-0C0h]
> >>>> 00BA13D2 mov ecx,30h
> >>>> 00BA13D7 mov eax,0CCCCCCCCh
> >>>> 00BA13DC rep stos dword ptr es:[edi]
> >>
> >> Assuming that this is correct, the basic answer is more or less
> what you’ve already been told. It’s marking the ‘beginning’ of the
> >> local stack with a some padding bytes that happen to the opcode
> for an ‘INT 3’ (0xCC). I’m not sure the specific purpose the
> >> compiler devs have in mind, but one thing it would definitely
> help with is diagnosing stack faults, which really suck to debug
> >> without some sort of cheating like this, because by the time you
> find out about the problem, you’re usually well away from the
> >> cause. With this technique, if you happen to end up outside the
> stack boundaries - within 0xC0 bytes in this case - the cpu will
> >> execute an 0xCC, a.k.a - INT 3, which will land you immediately
> in WinDbg, so you have a much better chance to figure out what the
> >> actual problem is more quickly, without having to traverse a
> blown stack, which itself can confuse WinDbg. So, from above:
> >>
> >>
> >>>> 00BA13C0 push ebp -> standard prolog:
> preserve the base pointer
> >>>> 00BA13C1 mov ebp,esp -> standard prolog: set
> the base pointer to the current stack pointer
> >>>> 00BA13C3 sub esp,0C0h -> standard prolog:
> create 0xC0 (in this case) bytes of local space on the stack
> >>>> 00BA13C9 push ebx -> preserve ebx (for
> later use)
> >>>> 00BA13CA push esi -> preserve esi (for
> later use)
> >>>> 00BA13CB push edi -> preserve edi (for
> use as target of ‘rep stos’)
> >>>> 00BA13CC lea edi,[ebp-0C0h] -> load the
> effective address of he first byte of the local space created in (2)
> >>>> 00BA13D2 mov ecx,30h -> set ecx (iterations of
> ‘stos’ to ‘rep’) 0x30==0xC0/sizeof(dword ptr)
> >>>> 00BA13D7 mov eax,0CCCCCCCCh -> set eax to the
> value of write to memory
> >>>> 00BA13DC rep stos dword ptr es:[edi] -> stores value in
> EAX to es:[EDI], then decrements ECX, ECX times
> >>
> >> The extra space could be used for some other purposes as well,
> some of which others have mentioned, like ‘Edit and Continue (-ZI’).
> >> As I said, I really don’t know the SPECIFIC purpose in this
> case, but this is the general idea. If you want to know the SPECIFIC
> >> reason, you’re going to need to find the compiler dev, or
> someone willing to speak for him.
> >>
> >> In general, George, you’re asking very detailed questions, on a
> very low level subject, that isn’t really on topic here, though
> >> that’s not really an issue, at least as far as I’m concerned.
> That being said, what I do find to be a little bit of an issue - not
> >> a big one - is that you seem to be unsatisfied with anything but
> the specific answer to the very question you are asking, all
> >> spelled out for you, on a topic like this - complicated, low
> level and not on topic, especially since you told us you haven’t read
> >> the Intel Manuals yet. Someone sent you a link to the Intel
> manuals - I would recommend that you read them thoroughly, because
> >> they are the best source for the answers to the types of
> questions that you are asking. If your questions were more on topic, or
> >> not on topic but at a higher level on a less complicated subject
> or had you already read the manual, then it wouldn’t be a problem,
> >> but for something like this, in my opinion, the etiquette here
> basically says that you have to take what you get for a question like
> >> this, and not keep posting until you get the very specific
> answer you want, and that people will lose patience if you don’t do your
> >> homework first. Don’t get me wrong - you clearly have been
> reading what people have suggested (like that article), but you don’t
> >> seem to understand that the entry level for material like this
> is reading Volumes 1, 2 & 3 of the Intel Manuals, and until you do
> >> that, you’re not going to be able to do anything useful with
> this information. That doesn’t mean you shouldn’t be told or even
> >> shouldn’t proceed this way, but understand that it will, in my
> opinion, make people want to help less.
> >>
> >> I hope that this is correct; it’s late, and I didn’t look very
> closely at the previous posts, but I think this is the general idea.
> >>
> >>
> >> Good luck,
> >>
> >> mm
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Lin George wrote:
> >>> Hi Calin,
> >>> I have read through the article you mentioned for a couple of
> hours. It is really good and I learned something which I donot know
> before, even if old day technologies.
> >>> But, seems it does not directly cover the answer to my
> question? Or I miss or misunderstand anything? Could you help to
> clarify please?
> >>> regards,
> >>> George
> >>>
> >>>
> >>> ----- Original Message ----
> >>> From: Calin Iaru > mailto:xxxxx>
> >>> To: Lin George > mailto:xxxxx>
> >>> Cc: xxxxx@lists.osr.com mailto:xxxxx
> >>> Sent: Wednesday, July 23, 2008 7:31:30 AM
> >>> Subject: Re: [windbg] strange 4 assembly instructions for a
> function
> >>>
> >>> The code you presented is code compiled on Win32 with Program
> Database for Edit and Continue set. If you use Program Database,
> then the code will look like:
> >>>
> >>> int f(int a, int b) {
> >>> 009911A0 push ebp
> >>> 009911A1 mov ebp,esp
> >>> return a+b;
> >>> 009911A3 mov eax,dword ptr [a]
> >>> 009911A6 add eax,dword ptr [b]
> >>> }
> >>> 009911A9 pop ebp
> >>> 009911AA ret
> >>>
> >>>
> >>> I don’t know why does PDEC arrange the code like this; perhaps
> is due to EC feature. PDEC implies the /Gy compiler switch which
> places each function definition in a code segment. The sum of these
> segments is the whole program; to make the code smaller, the linker
> has the option to remove all unused segments. An article written by
> Matt Pietrek specifies that the functions compiled with /Gy are
> aligned on a power of 2 boundary which means that each function will
> be padded with INT 3 instructions up to the next alignment.
> >>> http://www.microsoft.com/msj/archive/S572.aspx
> >>> or search for
> >>> Matt Pietrek comdat
> >>> on msdn.
> >>>
> >>> ----- Original Message ----
> >>> From: Lin George > mailto:xxxxx>
> >>> To: xxxxx@yahoo.com mailto:xxxxx
> >>> Cc: Kernel Debugging Interest List > mailto:xxxxx>
> >>> Sent: Tuesday, July 22, 2008 7:53:57 AM
> >>> Subject: Re: [windbg] strange 4 assembly instructions for a
> function
> >>>
> >>> Thanks Calin,
> >>> I fully agree with you from your below points. But don’t you
> think it initializes more stack space than actually needed?
> >>> I posted the assembly code again here. Any comments?
> >>> 00BA13CC lea edi,[ebp-0C0h]
> >>> 00BA13D2 mov ecx,30h
> >>> 00BA13D7 mov eax,0CCCCCCCCh
> >>> 00BA13DC rep stos dword ptr es:[edi]
> >>> regards,
> >>> George
> >>>
> >>>
> >>> ----- Original Message ----
> >>> From: Calin Iaru > mailto:xxxxx>
> >>> To: Kernel Debugging Interest List > mailto:xxxxx>
> >>> Sent: Monday, July 21, 2008 8:24:42 PM
> >>> Subject: Re: [windbg] strange 4 assembly instructions for a
> function
> >>>
> >>> Hi,
> >>>
> >>> the compiler fills with 0xCC about 0xC0 bytes of local stack
> data. I expect a release build to clean up the code.
> >>>
> >>> Best regards,
> >>> Calin
> >>>
> >>> PS.
> >>> 0xCC is a well known value which is distinctively recognized
> during a crash. For instance, if you have a pointer which contains
> this value, it will indicate that the pointer is not initialized.
> Other known value is an 0xfeeefeee which says that the pointer was
> released. For pointers, use the !address command to find out more
> information about wether the page was allocated or freed and so on.
> >>>
> >>> — On Mon, 7/21/08, Lin George > mailto:xxxxx> wrote:
> >>>
> >>>> From: Lin George > mailto:xxxxx>
> >>>> Subject: [windbg] strange 4 assembly instructions for a function
> >>>> To: “Kernel Debugging Interest List” > mailto:xxxxx>
> >>>> Date: Monday, July 21, 2008, 11:59 AM
> >>>> Hello everyone,
> >>>>
> >>>> I am confused what is the function of the 4 assembly
> >>>> instructions – I found them when debugging function prolog
> >>>> and epilog for study? I posted the 4 assembly instructions
> >>>> and related whole source code/assembly code below.
> >>>> Any ideas?
> >>>> <br>> >>>> 00BA13CC lea edi,[ebp-0C0h]<br>> >>>> 00BA13D2 mov ecx,30h<br>> >>>> 00BA13D7 mov eax,0CCCCCCCCh<br>> >>>> 00BA13DC rep stos dword ptr es:[edi]<br>> >>>><br>> >>>> int sumExample (int a, int b)<br>> >>>> {<br>> >>>> 00BA13C0 push ebp<br>> >>>> 00BA13C1 mov ebp,esp<br>> >>>> 00BA13C3 sub esp,0C0h<br>> >>>> 00BA13C9 push ebx<br>> >>>> 00BA13CA push esi<br>> >>>> 00BA13CB push edi<br>> >>>> 00BA13CC lea edi,[ebp-0C0h]<br>> >>>> 00BA13D2 mov ecx,30h<br>> >>>> 00BA13D7 mov eax,0CCCCCCCCh<br>> >>>> 00BA13DC rep stos dword ptr es:[edi]<br>> >>>> return a + b;<br>> >>>> 00BA13DE mov eax,dword ptr [a]<br>> >>>> 00BA13E1 add eax,dword ptr [b]<br>> >>>> }<br>> >>>> #include <iostream><br>> >>>> using namespace std;<br>> >>>> int sumExample (int a, int b)<br>> >>>> {<br>> >>>> return a + b;<br>> >>>> }<br>> >>>> int main()<br>> >>>> {<br>> >>>> int c = sumExample (100, 200);<br>> >>>> cout << c << endl;<br>> >>>> return 0;<br>> >>>> }<br>> >>>>
> >>>>
> >>>> thanks in advance,
> >>>> George
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> —
> >>>> You are currently subscribed to windbg as: unknown lmsubst
> >>>> tag argument: ‘’
> >>>> To unsubscribe send a blank email to
> >>>> xxxxx@lists.osr.com
> mailto:xxxxx
> >>>
> >>>
> >>>
> >>>
> >>> —
> >>> You are currently subscribed to windbg as: unknown lmsubst tag
> argument: ‘’
> >>> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
> >>>
> >>>
> >>>
> >>>
> >>
> >> —
> >> You are currently subscribed to windbg as:
> xxxxx@yahoo.com mailto:xxxxx
> >> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
> >>
> >>
> >>
> >>
> >>
> >> —
> >> You are currently subscribed to windbg as: unknown lmsubst tag
> argument: ‘’
> >> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
> >>
> >
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> mailto:xxxxx
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> mailto:xxxxx
>
>
>
>
>
>
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>