News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Static RSP built in JWasm

Started by habran, June 14, 2013, 03:39:17 PM

Previous topic - Next topic

japheth

Quote from: habran on June 29, 2013, 10:12:13 PM
If so, why would we go through the trouble to build it :(

:bgrin:

Questions about causality are my favorites. Perhaps because

  • we are bored and have nothing better to do?
  • it's an intellectual challenge?
  • we want to improve our skills in ???
  • for aesthetic reasons - to make the assembler "more complete"?  :icon_mrgreen:


habran

now you are talking... :t
I was just testing you ;)
so, what do you recon?
who will go through the trouble?
you, me or both? :biggrin:
Cod-Father

nidud

#17
deleted

jj2007

Quote from: sinsi on June 29, 2013, 10:17:04 PMI'm afraid there aren't five members here who know care what we're talking about.

Is it worth the effort? I can't speak for 64-bit code, but in 32-bit...
- [esp+n] instructions are longer than their [ebp+n] equivalents
- yes you can trace push & pop, even with simple macros, but it gets nasty if they happen inside branches or .if .elseif constructs
- performance is not a valid argument, because a) innermost loops should not call or invoke any code and b) if you really, really need ebp as an extra reg32, just push it before you enter the innermost loop.

So where is the real added value...?

habran

hey nidud
you have some good pints there :icon14:

hey jj2007,
where is your enthusiasm gone ;)

so, japheth
we have one person who is against (jj2007, as expected) :icon13:
one person who is for (nidud, as expected) :icon14:
and one who doesn't care (sinsi, unpredictable) :P

are you still on holidays or you want to role the slews?
Cod-Father

habran

hey japheth
I have figured out the switches for different debuggers
here are:
/* codeview debug info option flags */
enum cvoption_flags {
        CVO_STATICTLS = 1, /* handle static tls */
CVO_MSVC8     = 2, /* MSVC8 debugger */
CVO_MSVC10    = 4, /* MSVC10 debugger */
CVO_MSVC12    = 8, /* MSVC12 debugger */
};

so I use It like this:
option codeview:2  ;//create MSVC8 debug info


option codeview:8  ;//create MSVC12 debug info

I hvae tested it and it works fine

I still have to figure out WinDbg6.1, WinDbg6.2 and MSVC10 then I will post the code here

here is dbgcv.c code for this:

    } else {
len = sizeof( struct cv_symrec_bprel32 );
cv->ps = checkflush( cv->symbols, cv->ps, 1 + lcl->sym.name_size + len );
cv->ps_br32->sr.size = sizeof( struct cv_symrec_bprel32 ) - sizeof(uint_16) + 1 + lcl->sym.name_size;
cv->ps_br32->sr.type = S_BPREL32;
if ( ModuleInfo.cv_opt & CVO_MSVC12 ){
cv->ps_br32->offset = lcl->sym.offset - sym_ReservedStack->value - proc->e.procinfo->xmmsize; // MODIFIED JOHNSA
if (proc->e.procinfo->xmmsize)cv->ps_br32->offset;
if (lcl->sym.isparam)
{
cv->ps_br32->offset +=0x10; //MODIFIED by johnsa
if (proc->e.procinfo->xmmsize)cv->ps_br32->offset += (proc->e.procinfo->xmmsize);
}
}
else if ( ModuleInfo.cv_opt & CVO_MSVC8 ){
if (lcl->sym.isparam)
{
cv->ps_br32->offset = lcl->sym.offset + sym_ReservedStack->value + proc->e.procinfo->localsize + 8;// - 0x10; //MODIFIED by johnsa
if (proc->e.procinfo->xmmsize)cv->ps_br32->offset += proc->e.procinfo->xmmsize + 8;
}
else{
cv->ps_br32->offset = lcl->sym.offset + sym_ReservedStack->value + 16; // MODIFIED JOHNSA
if (proc->e.procinfo->xmmsize)cv->ps_br32->offset += proc->e.procinfo->xmmsize - 16;
}
}
else {
  cv->ps_br32->offset = lcl->sym.offset;
}
cv->ps_br32->type = lcl->sym.ext_idx1;
        DebugMsg(( "cv_write_symbol(%X): proc=%s, S_BPREL32, var=%s [memt=%X typeref=%X]\n",
                  GetPos(cv->symbols,cv->ps), proc->sym.name, lcl->sym.name, lcl->sym.mem_type, cv->ps_br32->type ));
    }

Cod-Father

habran

I have figured out debug info for debuggers available from MS and found out
that WinDbg 6.12. can not be used with this option because it uses RBP for locals ::)
so available debuggers are here:

/* codeview debug info option flags */
enum cvoption_flags {
        CVO_STATICTLS    = 1, /* handle static tls */
CVO_MSVC12       = 2, /* MSVC12 and MSVC10 debugger are the same */
CVO_WINDBG62     = 4, /* WinDbg 6.2.8400.0 debugger */
CVO_MSVC8        = 8, /* MSVC8 debugger */
};


I have also concluded that option without pushing RBP produces less code
and decided to stick with it
so I replaced the folder on the top with that option
Cod-Father

japheth

Quote from: habran on July 01, 2013, 06:15:24 AM
that WinDbg 6.12. can not be used with this option because it uses RBP for locals ::)

Yes, of course. This is not a debugger issue. If your compiler/assembler emits S_BPREL32 codeview debugging info, then the debugger will assume that [E|R]BP is setup as frame pointer. If [E|R]BP is NOT setup, you MUST NOT emit S_BPREL32 records ( instead use S_REGREL32 ).

Also, for me WinDbg ( various versions ) and MSVC ( 5, 6,8 (VC 2005), 9 (VC 2008) and 10 ( VC 2010) debuggers work very well displaying locals ( I didn't test VC 2012 because, AFAIK, this BS won't run with XP anymore ).

So unless you're providing a test case that will reveal to me what the problem is, I will have to leave everything as it is.

habran

I tried to change to S_REGREL32 but it wouldn't link:
Error   1   error LNK1103: debugging information corrupt; recompile module   
I have to admit that I am not familiar with dbgcv.c except the cv->ps_br32->offset

why is that that all other debuggers have no problem with S_BPREL32 but WinDBG 6.12?
QuoteSo unless you're providing a test case that will reveal to me what the problem is, I will have to leave everything as it is.
what do you mean with that constatation?
Cod-Father

japheth

Quote from: habran on July 02, 2013, 05:59:32 AM
I tried to change to S_REGREL32 but it wouldn't link:
Error   1   error LNK1103: debugging information corrupt; recompile module   

You probably just replaced S_BPREL32 by S_REGREL32? It's not THAT simple - the S_REGREL32 record has an additional field, a  "register number", which must be set. See codeview debug info documentation.

Quote
why is that that all other debuggers have no problem with S_BPREL32 but WinDBG 6.12?

I don't know ... must be a miracle ... perhaps the Hand of God.

Quotewhat do you mean with that constatation?

AFAIU, jphnsa reported this issue as a bug ( by PM ) - and I'm unable to see a bug.




habran

QuoteI don't know ... must be a miracle ... perhaps the Hand of God.

If you are trying to piss me off, you have to work harder on it ;)

QuoteYou probably just replaced S_BPREL32 by S_REGREL32? It's not THAT simple - the S_REGREL32 record has an additional field, a  "register number", which must be set. See codeview debug info documentation.

for you it would be a chicken shit to make it work, but you are on bloody holidays
so I have to sweat blood to make it ::)

anyway, don't feel sorry for me, as you said before, we have to push these brains of us if we want to
keep them
if you stay a little bit longer on the vacation I will eventually become as smart as you are :biggrin: 
Cod-Father

habran

I have left only version with no RBP pushed
debug info available:
MSVC12        = option codeview:2
WINDBG 6.2  = option codeview:4 
MSVC8          = option codeview:8
8)
Cod-Father

habran

I have found out how to use S_REGREL32 and that fixes everything
thanks to you japheth's sugestion, now all MS debuggers work properly :t
there is no more need to use "option codeview:"
It took me whole week of surfing the internet to find info for RSP value which is 335
it is contained in cvconst.h

using the struct:

struct cv_symrec_regrel32 { /* REGREL32 */
struct cv_symrec sr;  
int_32 offset; /* offset of symbol */
        uint_16  reg; /* register index for symbol */
cv_typeref type; /* Type index */
    //unsigned char   name[1];  /* Length-prefixed name */
}; //REGREL32 added by habran



if (ModuleInfo.win64_flags & W64F_STATICRSP){
  len = sizeof( struct cv_symrec_regrel32 );
  cv->ps = checkflush( cv->symbols, cv->ps, 1 + lcl->sym.name_size + len );
  cv->ps_rr32->sr.size = sizeof( struct cv_symrec_regrel32 ) - sizeof(uint_16) + 1 + lcl->sym.name_size;
  cv->ps_rr32->sr.type = S_REGREL32;// replaced S_BPREL32
  cv->ps_rr32->reg = CV_AMD64_RSP; // use RSP register
cv->ps_rr32->offset = lcl->sym.offset + sym_ReservedStack->value ;
if ((proc->e.procinfo->ReservedStack > 32)) cv->ps_rr32->offset += 16;
if (lcl->sym.isparam)
{
  cv->ps_rr32->offset +=0x10;
  if (proc->e.procinfo->xmmsize)cv->ps_rr32->offset += proc->e.procinfo->xmmsize;
}
  cv->ps_rr32->type = lcl->sym.ext_idx1;
  DebugMsg(( "cv_write_symbol(%X): proc=%s, S_BPREL32, var=%s [memt=%X typeref=%X]\n",
     GetPos(cv->symbols,cv->ps), proc->sym.name, lcl->sym.name, lcl->sym.mem_type, cv->ps_rr32->type ));
}
Cod-Father

japheth

Quote from: habran on July 06, 2013, 08:46:35 PM
It took me whole week of surfing the internet

In case it was the first time: welcome to the pleasure of chasing undocumented M$ stuff!  :bgrin:

Quote
to find info for RSP value which is 335
it is contained in cvconst.h

Nice find and valuable information! I knew that register number for RBP was 334 ( because that is what ML64 emits, it has obviously abandoned S_BPREL32 ), but would have assumed that the number for RSP is 333 then ( this would have matched the Intel register ordering ).,

habran

thanks japheth :biggrin:
I am very pleased that I succeeded to make everything working as I planed
felling of success is the greatest reword for a hard work
it doesn't matter if only a few people understand the value of your work
these few people count :t
Cod-Father