Hello,

At my company we are quite stymied trying to find a solution to our 
assembly needs. We have a C project (actually, C++ project, but we know 
how to handle the C++ to ASM interface) which compiles on both Windows 
and Linux, using the Visual Studio and GCC respectively. We also compile 
with GCC on Windows, so supporting that would be great. We need to 
integrate some assembly code which we plan to do by having a .h file 
with the function declarations and a .asm file with the actual code.

We have gotten MASM to compile and generate debuggable code on Windows, 
and we have gotten NASM to do the same on Linux, but as far as our 
knowledge of the assemblers is limited, this requires re-writing parts 
of the .asm file for each compiler. We were able to get NASM to compile 
the same code on Windows and link it with our application, but Visual 
Studio would not debug into our assembly code. We assume NASM can't 
generate the Windows-specific debugging symbols.

Is there an assembler that will generate debugging symbols in both win32 
and ELF formats? Or alternatively, how do we go about writing an asm 
file in a way that both MASM and NASM will be happy with?

I understand that both assemblers understand the same syntax, it seems 
that the 'setup' code before the actually assembly is the problem.

Thanks for any help you can provide,

Josh Pollak
Software Engineer
Charles River Analytics

Despite all prevention efforts, Joshua Pollak  <spamtrap@crayne.org> wrote 
in news:41DEE7BE.9040307@offthehill.org:

> We have gotten MASM to compile and generate debuggable code on Windows, 
> and we have gotten NASM to do the same on Linux, but as far as our 
> knowledge of the assemblers is limited, this requires re-writing parts 
> of the .asm file for each compiler. We were able to get NASM to compile 
> the same code on Windows and link it with our application, but Visual 
> Studio would not debug into our assembly code. We assume NASM can't 
> generate the Windows-specific debugging symbols.
> 
> I understand that both assemblers understand the same syntax, it seems 
> that the 'setup' code before the actually assembly is the problem.
> 

Can you not conditionally include the differing pieces of setup code via 
some platform-specific .INC files?  Your build process can predefine a 
macro for the assembler to know which file(s) to include.  But maybe I'm 
over-simplifying...?

Not sure about generating Windows debug symbols from NASM...

-- 
Slor

Joshua Pollak <spamtrap@crayne.org> wrote:
> Hello,

> At my company we are quite stymied trying to find a solution to our 
> assembly needs. We have a C project (actually, C++ project, but we know 
> how to handle the C++ to ASM interface) which compiles on both Windows 
> and Linux, using the Visual Studio and GCC respectively. We also compile 
> with GCC on Windows, so supporting that would be great. We need to 
> integrate some assembly code which we plan to do by having a .h file 
> with the function declarations and a .asm file with the actual code.

> We have gotten MASM to compile and generate debuggable code on Windows, 
> and we have gotten NASM to do the same on Linux, but as far as our 
> knowledge of the assemblers is limited, this requires re-writing parts 
> of the .asm file for each compiler. We were able to get NASM to compile 
> the same code on Windows and link it with our application, but Visual 
> Studio would not debug into our assembly code. We assume NASM can't 
> generate the Windows-specific debugging symbols.

> Is there an assembler that will generate debugging symbols in both win32 
> and ELF formats? Or alternatively, how do we go about writing an asm 
> file in a way that both MASM and NASM will be happy with?

> I understand that both assemblers understand the same syntax, it seems 
> that the 'setup' code before the actually assembly is the problem.

> Thanks for any help you can provide,

> Josh Pollak
> Software Engineer
> Charles River Analytics

There is no one assembler that I know of that does what you want. I
would suggest using NASM for both Windows and Linux.  This is pretty
straightforward. See my website for examples.

As for debugging, I have found that one can debug NASM code in Visual
Studio without having the symbols pretty effectively. Just view the
code in the assembly window. You don't see the names of internal 
symbols, just the values, but you can single step, set breakpoints
and see register values.

NASM does support gdb debugging so Linux is not a problem.

-- 
Paul Carter 
http://www.drpaulcarter.com/pcasm

Joshua Pollak wrote:

> We assume NASM can't
> generate the Windows-specific debugging symbols.

This is true. However, Nasm is open source, and anyone is free to modify
it. There's a "skeleton" of sorts in place for adding debug info to an
output format. You'd have to provide routines to emit the actual
symbolic information, but then you just plug 'em into a predefined
structure, and using the "-g" switch will enable it (as you've probably
noticed, "-g" is currently silently ignored in "-f win32"). Nasm'll even
report that it's there, with "-f win32 -y"...

"Fix the assembler so it does what you want" probably wasn't the answer
you were looking for, but it might be your best option. I'm surprised no
one has done it - it's a fairly common complaint. I assume the format of
the symbolic info is known, or can be discovered. You've got some
examples of what you need, in the Masm code... I don't know how
difficult this would be, but maintaining two versions of the code can't
be a picnic! Source that will assemble with either Masm or Nasm is...
impractical, if even possible - the syntax differs *just* enough...

"-f win32" isn't my format, and I'm not a C programmer, so I won't be
much help, but I'll stand on the sidelines and shout encouragment! :)

Best,
Frank

On Fri, 7 Jan 2005 20:59:40 +0000 (UTC), Joshua Pollak
<spamtrap@crayne.org> wrote:

>Hello,
>
>At my company we are quite stymied trying to find a solution to our 
>assembly needs. We have a C project (actually, C++ project, but we know 
>how to handle the C++ to ASM interface) which compiles on both Windows 
>and Linux, using the Visual Studio and GCC respectively. We also compile 
>with GCC on Windows, so supporting that would be great. We need to 
>integrate some assembly code which we plan to do by having a .h file 
>with the function declarations and a .asm file with the actual code.
>
>We have gotten MASM to compile and generate debuggable code on Windows, 
>and we have gotten NASM to do the same on Linux, but as far as our 
>knowledge of the assemblers is limited, this requires re-writing parts 
>of the .asm file for each compiler. We were able to get NASM to compile 
>the same code on Windows and link it with our application, but Visual 
>Studio would not debug into our assembly code. We assume NASM can't 
>generate the Windows-specific debugging symbols.
>
>Is there an assembler that will generate debugging symbols in both win32 
>and ELF formats? Or alternatively, how do we go about writing an asm 
>file in a way that both MASM and NASM will be happy with?
>
>I understand that both assemblers understand the same syntax, it seems 
>that the 'setup' code before the actually assembly is the problem.
>
>Thanks for any help you can provide,

I had somewhat the same problem when I was porting BCET to FreeBSD.

So, I wrote a little MASM to NASM conversion program: M2N.

It is still in the alpha stage of development, but if you want to try
it, send me an email (fix the reply address as in the SIG), and I will
send you a copy along with what minuscule bit of documentation there
is. (actually there isn't any, I would have to write it.)  M2N works
(mostly) for my programming style, but since MASM has such a complex
syntax, it could easily not work for anyone else.  

In some cases, I have to include both Masm and Nasm style code in the
source.  M2N recognizes several predefines to make this possible.


-- 
Arargh501 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

spamtrap@crayne.org (arargh) wrote:

> I had somewhat the same problem when I was porting BCET to FreeBSD.
> 
> So, I wrote a little MASM to NASM conversion program: M2N.

Good solution! I should have thought of that (I did a little
"beta-testing" of M2N when I was still running Windows, and can confirm
that it works... somewhat imperfect, but a *big* help!).

I'd still like to see someone add the debugging format to Nasm...

Best,
Frank

On Mon, 10 Jan 2005 02:41:47 +0000 (UTC), Frank Kotler
<spamtrap@crayne.org> wrote:

>spamtrap@crayne.org (arargh) wrote:
>
>> I had somewhat the same problem when I was porting BCET to FreeBSD.
>> 
>> So, I wrote a little MASM to NASM conversion program: M2N.
>
>Good solution! I should have thought of that (I did a little
>"beta-testing" of M2N when I was still running Windows, and can confirm
>that it works... somewhat imperfect, but a *big* help!).

More like "alpha-testing" :-)

Current Version:
 M2N - MASM to NASM Translater (FLAT mode only) - Version 0.01 (Alpha)

>I'd still like to see someone add the debugging format to Nasm...

Considering that, IIRC, VC and MASM still use some variant of the old
CodeView format, Do you (or anyone else) know where to get a GOOD spec
on it?

-- 
Arargh501 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

Frank Kotler wrote:
[...]
> "Fix the assembler so it does what you want" probably wasn't the
> answer you were looking for, but it might be your best option. I'm
> surprised no one has done it - it's a fairly common complaint. I
> assume the format of the symbolic info is known, or can be
> discovered.

Visual Studio requires a PDB file for debugging. Unfortunately, noone has
managed to get MS to give out any information on this format, except that it
was originally (at the time of Visual Studio 1.0) derived from CodeView. It
doesn't help that the format changes with each version of VS either ...

Some people (such as the Wine developers) have had some limited success in
reverse engineering the format to extract information, but I'm unaware of
anyone who has actually managed to generate a valid PDB file of any version.

[...]

-- 
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :)
Add michael@ to emboss.co.nz ---+--- My inbox is always open

Michael Brown wrote:

> Visual Studio requires a PDB file for debugging. Unfortunately, noone has
> managed to get MS to give out any information on this format, except that it
> was originally (at the time of Visual Studio 1.0) derived from CodeView. It
> doesn't help that the format changes with each version of VS either ...
> 
> Some people (such as the Wine developers) have had some limited success in
> reverse engineering the format to extract information, but I'm unaware of
> anyone who has actually managed to generate a valid PDB file of any version.

Oh, dear! Well, that explains why no one has devised a patch for Nasm.
Thanks.

Best,
Frank

Frank Kotler <spamtrap@crayne.org> wrote:
> Michael Brown wrote:

>> Visual Studio requires a PDB file for debugging. Unfortunately, noone has
>> managed to get MS to give out any information on this format, except that it
>> was originally (at the time of Visual Studio 1.0) derived from CodeView. It
>> doesn't help that the format changes with each version of VS either ...
>> 
>> Some people (such as the Wine developers) have had some limited success in
>> reverse engineering the format to extract information, but I'm unaware of
>> anyone who has actually managed to generate a valid PDB file of any version.

> Oh, dear! Well, that explains why no one has devised a patch for Nasm.
> Thanks.

> Best,
> Frank

I'm pretty sure the PDB file is produced by the MS linker from the
object files. So one doesn't need to understand the format of the PDB
file, just the format that debugging info is put in the object file,
right? Or am I missing something?

-- 
Paul Carter 

spamtrap@crayne.org wrote:

> I'm pretty sure the PDB file is produced by the MS linker from the
> object files. So one doesn't need to understand the format of the PDB
> file, just the format that debugging info is put in the object file,
> right? Or am I missing something?
> 
> --
> Paul Carter

I don't know. If true, then it *should* be possible to modify Nasm... if
*that* format is known, or can be discovered...

As you pointed out, it is possible to debug without the symbol info, but
should be a lot nicer with it!

If Joshua can do a compare of the Masm and Nasm .objs, it might help.
Nasm is well-suited to do what he wants, I think, except for this
problem.

Best,
Frank

On Mon, 10 Jan 2005 04:36:39 +0000 (UTC), spamtrap@crayne.org wrote:

>On Mon, 10 Jan 2005 02:41:47 +0000 (UTC), Frank Kotler
><spamtrap@crayne.org> wrote:
>
>>spamtrap@crayne.org (arargh) wrote:
>>
>>> I had somewhat the same problem when I was porting BCET to FreeBSD.
>>> 
>>> So, I wrote a little MASM to NASM conversion program: M2N.
>>
>>Good solution! I should have thought of that (I did a little
>>"beta-testing" of M2N when I was still running Windows, and can confirm
>>that it works... somewhat imperfect, but a *big* help!).
>
>More like "alpha-testing" :-)
>
>Current Version:
> M2N - MASM to NASM Translater (FLAT mode only) - Version 0.01 (Alpha)
>
>>I'd still like to see someone add the debugging format to Nasm...
>
>Considering that, IIRC, VC and MASM still use some variant of the old
>CodeView format, Do you (or anyone else) know where to get a GOOD spec
>on it?

Found it: it's in the MSDN library under:

"Visual C++ 5.0 Symbolic Debug Information Specification"

-- 
Arargh501 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

spamtrap@crayne.org wrote:

> >CodeView format, Do you (or anyone else) know where to get a GOOD spec
> >on it?
> 
> Found it: it's in the MSDN library under:
> 
> "Visual C++ 5.0 Symbolic Debug Information Specification"

Great. Thanks, Arargh! Uh... sorry to be such an idiot - I have no idea
how to navigate MSDN. I typed the above into the "search" box, and
didn't come up with anything that seemed vaguely useful... or maybe I
was looking right at it and didn't recognize it. I'm going to need a
*lot* of help if this is going to happen!

How about you, Joshua? Are you still with us? If we can make this fly,
do you think you'd use it? Are you in a position to help, at all? If I
can get any expression of enthusiasm, I'll put out a cry for help on the
nasm-devel list, too. Hell, I'll cc this to the list. Won't hurt, even
though we're otherwise occupied at the moment. Maybe there's some
enthusiasm there...

Can I at least hear a "Hoo Rah, Seargent!" on this from anywhere?

Best,
Frank

On Wed, 12 Jan 2005 08:47:15 +0000 (UTC), Frank Kotler
<spamtrap@crayne.org> wrote:

>spamtrap@crayne.org wrote:
>
>> >CodeView format, Do you (or anyone else) know where to get a GOOD spec
>> >on it?
>> 
>> Found it: it's in the MSDN library under:
>> 
>> "Visual C++ 5.0 Symbolic Debug Information Specification"
>
>Great. Thanks, Arargh! Uh... sorry to be such an idiot - I have no idea
>how to navigate MSDN. I typed the above into the "search" box, and
>didn't come up with anything that seemed vaguely useful... or maybe I
>was looking right at it and didn't recognize it. I'm going to need a
>*lot* of help if this is going to happen!

I can't find it online, either.  I got it off an older version of the
MSDN CD.  It's in "specs.chm", the last entry.

I even found the 16-bit version on an even older MSDN CD (1977).


>How about you, Joshua? Are you still with us? If we can make this fly,
>do you think you'd use it? Are you in a position to help, at all? If I
>can get any expression of enthusiasm, I'll put out a cry for help on the
>nasm-devel list, too. Hell, I'll cc this to the list. Won't hurt, even
>though we're otherwise occupied at the moment. Maybe there's some
>enthusiasm there...
>
>Can I at least hear a "Hoo Rah, Seargent!" on this from anywhere?
>
>Best,
>Frank

-- 
Arargh501 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

Joshua Pollak <spamtrap@crayne.org> wrote:

> [...] but Visual Studio would not debug into our [NASM] assembly code.

Maybe Borland's C++ Builder will.