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 |
|
Tomasz Grysztar 16 Mar 2009, 16:57
BTW (sorry for another off-topic ), 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). |
|||
16 Mar 2009, 16:57 |
|
buzzkill 16 Mar 2009, 18:30
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 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 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 (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... |
|||
16 Mar 2009, 18:30 |
|
Tomasz Grysztar 16 Mar 2009, 18:49
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 buzzkill wrote: Why won't you add this 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. |
|||
16 Mar 2009, 18:49 |
|
comrade 16 Mar 2009, 21:21
Tomasz Grysztar wrote:
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). |
|||
16 Mar 2009, 21:21 |
|
comrade 17 Mar 2009, 01:47
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 I wasn't sure what platform you were talking about your original statement, that's why I mentioned the separate file. |
|||
17 Mar 2009, 01:47 |
|
rugxulo 17 Mar 2009, 04:04
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.) |
|||
17 Mar 2009, 04:04 |
|
rugxulo 17 Mar 2009, 04:16
Quote:
But not on all targets. I think YASM even has better support for some. Quote:
OpenWatcom also can do this, making it separate (though I forget which formats). |
|||
17 Mar 2009, 04:16 |
|
Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.