flat assembler
Message board for the users of flat assembler.

Index > Linux > Linking object files: do you use ld or gcc?

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
BTW (sorry for another off-topic Wink), it would be really great, if some programmer knowledgable with Linux found some free time and determination to make some tool for converting .fas info into some debug info format useable on Linux/Unix systems, like stabs of DWARF - just like strap89 has recently done converted into CodeView format. It's highly unlikely I'll do it myself, so I encourage anyone who would feel like doing this, to start such project.

As for me, I'm now going to work on the documentation updates for the 1.68 milestone (there's quite a lot of them overdue), and then maybe starting thinking about fasmx project and Mach-O output support (I'm not yet sure, which one first).
Post 16 Mar 2009, 16:57
View user's profile Send private message Visit poster's website Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
Tomasz,

Quote:
With libc package comes the README.TXT file...


Unfortunately this readme isn't shipped with the linux version of fasm, so I never saw it Smile Maybe it's an idea to include that file in the linux version as well? (But you're right, using "main" as entry point should have been a clue for me Smile And that also explains your view of the stack, you expect it to have been setup by gcc.)


On your post next post, about the debug info:

Why won't you add this yourself? It seems to me that outputting debug info is a core function of a compiler/assembler. Other assemblers like eg nasm output this info themselves too. I would think you'd like to control this yourself, and not have this functionality in a "third-party add-on" so to speak.
Because the "usual" way to add debug info to an executable is not to generate a seperate file for it that has to be converted by another tool in order to be used, but to have the debug info included in the executable itself, because that's much easier to work with.

I think that having fasm behave more like a standard/gnu/linux tool would increase its adoption on linux, and playing nice with debuggers is definately a part of that. (The same thing can be said for generating preprocessed output btw, just like linux compilers all have a -g switch for outputting debug info, they also have an -E switch for outputting preprocessor info).

BTW, Dwarf (http://dwarfstd.org/Home.php) is the "modern" debug info format on linux. I was going to say dwarf2, but I see they're already up to v3 Smile (although I don't think many standard tools support this yet). I don't know anything about Dwarf internals though, and am not an experienced asm coder at all, so I don't think I can help you, but I would be willing to help out if I can. But, like I said above, I really think you should consider implementing this in fasm itself...
Post 16 Mar 2009, 18:30
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7797
Location: Kraków, Poland
Tomasz Grysztar
buzzkill wrote:
Because the "usual" way to add debug info to an executable is not to generate a seperate file for it that has to be converted by another tool in order to be used, but to have the debug info included in the executable itself, because that's much easier to work with.

Actually, I think having it in separate file may sometimes have an advantage, because this way you can have debug info even for the production-stage executable, and you can trace faults reported after the release. And keep in mind, that not all of the formats, that fasm generates, would be able to accomodate that kind of information. And I prefer universal solutions (see below).

buzzkill wrote:
The same thing can be said for generating preprocessed output btw, just like linux compilers all have a -g switch for outputting debug info, they also have an -E switch for outputting preprocessor info
The problem here is that I don't want fasm to adopt to the standards of any given OS - I want exactly the opposite, I keep fasm behaving the same way regardless of the OS, in which it operates. That's part of the implementation of the SSSO principle.

buzzkill wrote:
Why won't you add this yourself?
I prefer to provide one universal format, which accumulates the fasm-specific stuff, which can be later processed into various other formats with specific tools. This is my way of allowing some of development to be done by community, since I keep the core under my complete control and don't use any contributions to it - however there are some active programmers willing to make additional tools and extensions (just like fasmarm project). If I had to write support for all those additional formats myself, you'd perhaps had to wait much longer - but now, with availability of documented fas format, you can make use of it and make various converters yourself.

This idea was born at our first fasm "technical discussion meeting" in 2006, when I was aware I may no longer be able to keep the enough speed of development for all features, which fasm still lacks, and moving this problem out of the fasm's core seemed like the best solution. And this format also keeps me satisfied, as it is able to keep all the fasm's specific information, while other debug info formats (created with a little different compiler approach in mind) may not have been so appropriate for this.

In fact, it is my "Complex Solutions With Simple Features" principle at work. Smile
Post 16 Mar 2009, 18:49
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
Tomasz Grysztar wrote:
buzzkill wrote:
Because the "usual" way to add debug info to an executable is not to generate a seperate file for it that has to be converted by another tool in order to be used, but to have the debug info included in the executable itself, because that's much easier to work with.

Actually, I think having it in separate file may sometimes have an advantage, because this way you can have debug info even for the production-stage executable, and you can trace faults reported after the release.


ACTUALLY, having the debug info in a separate file IS the usual way, at least in the MSFT world. Exactly for the reason Tomasz mentioned. MSFT even keeps a public symbol server (serving "public" symbols - debug info with local variables and other information stripped out).

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 16 Mar 2009, 21:21
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
buzzkill



Joined: 15 Mar 2009
Posts: 111
Location: the nether lands
buzzkill
comrade,

Quote:
ACTUALLY, having the debug info in a separate file IS the usual way, at least in the MSFT world.


So does that mean that Windows compilers/assemblers have an option to generate a separate file containing the debug info during compilation? Because I don't know of an easy way to coax linux tools such as gcc or nasm into doing that, the only way I know on linux to separate the debug info from the rest of the executable is through objcopy. (If any linux person out there knows a better way, please let me know).

Tomasz,

Thanks for pointing me to your Design Principles document, it was an interesting read. (I can vaguely remember playing with tasm/masm a bit myself in the good old DOS days Smile ).
And I do see some advantages to keeping the debug info separated, it's just that I've never used that approach myself.

I'll try to read up a little on dwarf and your .fas format, in the hope that I might be able to contribute something, but like I said, I'm not the guy to take on writing that stuff from scratch myself Smile

PS. I just noticed that nasm does support dwarf3, so that shows you how up to date I am on the matter Wink
Post 16 Mar 2009, 22:31
View user's profile Send private message Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation
comrade
buzzkill wrote:
So does that mean that Windows compilers/assemblers have an option to generate a separate file containing the debug info during compilation? Because I don't know of an easy way to coax linux tools such as gcc or nasm into doing that, the only way I know on linux to separate the debug info from the rest of the executable is through objcopy.


Yes, at least the MSFT VC link.exe can generate the PDB debug info file via a /PDB switch.

Unix has been traditionally different in that the debug info is merged with the executable... and I have no idea about objcopy or any other tools Smile

I wasn't sure what platform you were talking about your original statement, that's why I mentioned the separate file.

_________________
comrade (comrade64@live.com; http://comrade.ownz.com/)
Post 17 Mar 2009, 01:47
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
buzzkill wrote:
But gas is the de facto assembler on linux ofcourse because it's the backend for gcc (incidentally, people used to say that gas wasn't that suitable as a standalone assembler for precisely that reason).


GAS isn't as crappy as it used to be (though I've never exhaustively tested it or anything). In particular, it was originally known for occasionally producing bad code, having very few syntax checks, being one-pass, AT&T only (even for Intel x86 target, which no one else used there), as well as not supporting 16-bit code at all (at least, not directly).

All of this has been improved (or completely fixed), so it's suitable now for most things. Still, doesn't mean I personally prefer it over NASM or FASM, but it's not too bad anymore. (BTW, Ohloh claims its codebase is worth $27.6 million.)
Post 17 Mar 2009, 04:04
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Quote:

PS. I just noticed that nasm does support dwarf3, so that shows you how up to date I am on the matter Wink


But not on all targets. I think YASM even has better support for some.

Quote:

Yes, at least the MSFT VC link.exe can generate the PDB debug info file via a /PDB switch.

Unix has been traditionally different in that the debug info is merged with the executable... and I have no idea about objcopy or any other tools Smile


OpenWatcom also can do this, making it separate (though I forget which formats).
Post 17 Mar 2009, 04:16
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.