Index
> Linux > fasdump : program to dump contents of fas filesGoto page 1, 2 Next |
| Author |
|
|
buzzkill 04 Apr 2009, 21:38
Hi all,
To teach myself the structure of the fas file format, I whipped up a small program to display the contents of these symbolic info files (generated with fasm -s). I wrote it in C because I'm more familiar with C than with assembly, though I'm planning on converting it to assembly later. Just in case this is useful to anyone, maybe as a sort of readelf/objdump like utility, I'm posting it here. I've tried to keep it as portable as possible (C99), but I've only tested it on linux/elf. If anyone has any questions or finds any bugs, just let me know.
|
|||||||||||
04 Apr 2009, 21:38 |
|
|
vid 05 Apr 2009, 10:05
I don't think it is anyhow important to convert it into assembly. You will just lose portability.
|
|||
|
05 Apr 2009, 10:05 |
|
|
Tomasz Grysztar 05 Apr 2009, 21:00
I've added it to the official list.
|
|||
|
05 Apr 2009, 21:00 |
|
|
buzzkill 05 Apr 2009, 21:07
Wow thanks, I made the official list
 Now to hope that no horrible bugs are discovered  |
|||
|
05 Apr 2009, 21:07 |
|
|
vid 05 Apr 2009, 21:29
Or you can just call standard C library from assembly. (Since libc is only defined at C source code level, and doesn't have ABI, you may need to include a very thin layer to achieve portability between various libc implementations. But that is not a problem)
|
|||
|
05 Apr 2009, 21:29 |
|
|
buzzkill 05 Apr 2009, 21:58
Well, this is something I've been thinking about (and maybe will start another thread about), what std library to use for assembly programming: libc, an asm lib, or write everything from scratch? On one hand, I think if you use libc, then why not just write in C, right? With today's compilers, for probably like 95% of the time, you get code that is very acceptable when compared to hand-coded assembly. On the other hand, writing everything from scratch would take an awful long time before you get a 'workable' library and can start to speed up your assembly development. Maybe something like a libasm is the solution?
|
|||
|
05 Apr 2009, 21:58 |
|
|
Madis731 06 Apr 2009, 06:37
I'm having quite a few problems with your code:
1) There's no getopt.h on my machine and seems that its not even C99, but some call it POSIX?! After I got my GNU C header from the net, I stumbled on another problem: 2) inttypes.h missing from my maching 
Seems that Intel Compiler isn't C99 compliant, though my string is: "icl /Qstd=c99 fasdump.c" After I got my hands on Visual Studio's C9x inttypes.h, there was a third problem... 3) It needed the stdint.h file, but this was made by Paul Hsieh Now the headers are a total mess  because I couldn't find the right ones and the result is something like this:
EDIT: I posted my improvements in the next post. Last edited by Madis731 on 06 Apr 2009, 07:51; edited 1 time in total |
|||
|
06 Apr 2009, 06:37 |
|
|
revolution 06 Apr 2009, 06:50
Is there an SSSO version of C?
 |
|||
|
06 Apr 2009, 06:50 |
|
|
Madis731 06 Apr 2009, 07:35
Yeah I've wondered that myself too. They say C is portable. My a$$ it is
I went the lengths of downloading some GNU C headers (they're not easily available and now I've got myself a Cygwin, but these headers don't make life easier:
EDIT: Step-by-step: 1) List of files: fasdump.c fasdump.h getopt.h getopt.c inttypes.h stdint.h getopt.c 2) icl /c /Qstd=c99 getopt.c Files added: +getopt.obj ~3KB 3) icl /Qstd=c99 fasdump.c /link getopt.obj Files added: +fasdump.obj ~30KB Only one dependancy remaining: Code: D:\>icl /Qstd=c99 fasdump.c /link getopt.obj Intel(R) C++ Compiler for applications running on Intel(R) 64, Version 10.1 B uild 20080312 Package ID: w_cc_p_10.1.021 Copyright (C) 1985-2008 Intel Corporation. All rights reserved. fasdump.c fasdump.c(273): warning #181: argument is incompatible with corresponding format string conversion printf("%-*s %-*s %-*s %s\n", sizeof(s_name), s_name, ^ fasdump.c(274): warning #181: argument is incompatible with corresponding format string conversion sizeof(s_dsize), s_dsize, sizeof(s_sectn), s_sectn, ^ fasdump.c(274): warning #181: argument is incompatible with corresponding format string conversion sizeof(s_dsize), s_dsize, sizeof(s_sectn), s_sectn, ^ Microsoft (R) Incremental Linker Version 8.00.40310.39 Copyright (C) Microsoft Corporation. All rights reserved. -out:fasdump.exe getopt.obj fasdump.obj fasdump.obj : error LNK2019: unresolved external symbol getopt_long referenced i n function main fasdump.exe : fatal error LNK1120: 1 unresolved externals I will post a solution if I ever get to that 
Maybe this source compiled for Cygwin and executed under Windows will work? Still there's the problem of getting it to compile... |
|||
|
06 Apr 2009, 07:35 |
|
|
vid 06 Apr 2009, 08:12
C99 is in fact a bad idea for portability. For example, one of reasons would be that none of existing compilers supports it completely to date. The real standard is C89/C90, and even that has some problems (MSVC doesn't support some of quite important features, like stdint or getopt).
Madis: I'd suggest you to download mingw C++ (that is GNU C++ ported to win32, not cygwin), and use that to compile linux C code. buzzkill: Your chain of thoughts leads to the conclusion everyone arrives to after some time: for most of applications today writing them in asm is not a best idea. Exceptions are things where size of code really matters (firmware), or computationally difficult tasks where speed needs to be completely maxed out (distributed computing, like SETI@Home or Folding@Home). In most such cases, reasons for using assembly are also reasons not to use any generic code library, but to craft all code for your specific purpose. Otherwise, with just _knowing_ assembly and writing C code, you are in most cases more productive, with only insignificant decrease in size/speed of resultant code. |
|||
|
06 Apr 2009, 08:12 |
|
|
Madis731 06 Apr 2009, 09:35
Okay, got it working. I dl-ed the MinGW and ran gcc. <errno.h> is not needed. Makes the executable double the size (28 vs. 56KB).
fasmdump will output some macro-magic example just fine, but the EFI-example hangs for a few seconds and I guess it ends with some memory violation. |
|||
|
06 Apr 2009, 09:35 |
|
|
buzzkill 06 Apr 2009, 12:25
Madis731,
Sorry to hear you're having problems with the code, I should have made it clearer that it was intended for *nix as-is, and would need some work on other platforms. Something like eg getopt is used in pretty much all linux cli programs, so I didn't go through the trouble of developing another cross-platform solution myself. errno.h is needed for me, for "errno" in line 464, I don't know why you don't need it. inttypes.h is C99, and includes stdint.h. If you, or anybody else, wants to port fasdump to other platforms, please do, I only have access to linux atm. Can you post the "EFI-example" you mention, so I can test this myself? vid: Yes, that sums it up nicely. That's also the reason why I wrote fasdump in C instead of asm. Still, it's fun to program in assembly, even if it is just small, educational programs. |
|||
|
06 Apr 2009, 12:25 |
|
|
Endre 08 Apr 2009, 10:13
Is defining variables in header file just another phantasmagoria of yours or is there also any reason for it?
|
|||
|
08 Apr 2009, 10:13 |
|
|
buzzkill 08 Apr 2009, 17:13
Don't get your panties in a wad, it's just some sloppy cut-n-pasting going from src->src+header. And in this case the result is the same, so it doesn't really matter, but yes, this time you've actually got a valid point, the globals are in the wrong place.
|
|||
|
08 Apr 2009, 17:13 |
|
|
Madis731 08 Apr 2009, 17:15
|
|||
|
08 Apr 2009, 17:15 |
|
|
buzzkill 08 Apr 2009, 18:16
Madis731 wrote: Example: here you go - http://x86asm.net/articles/uefi-programming-first-steps/index.html#UEFI-Programming-with-FASM Hmm yes, that's not an elf binary, so I'm not surprised it doesn't work. My little program only handles elf binaries on linux, that's why I posted it in the linux section of the forum. Since I only run linux myself, that means that if anybody wants support for other platforms/binary formats, they will have to add this themselves. So I'm sorry if this is not what you wanted to hear, but my program was only written to teach myself about the fas format (as it applies to elf), nothing else. I tried to make this clear in my initial post. Tomasz: perhaps you should either remove this program from your official list, or else add a warning that it's linux/elf only? |
|||
|
08 Apr 2009, 18:16 |
|
|
Tomasz Grysztar 08 Apr 2009, 18:40
I changed the description.
|
|||
|
08 Apr 2009, 18:40 |
|
|
Madis731 09 Apr 2009, 15:47
Don't worry, buzzkill, as you may have read, the source finally compiled when I downloaded the right tools
So that is a No-Bug...
I understood that this is Linux/ELF-only, but still one could use that program with simple binaries (headerless) files, as I did with a macro-based image generator. The output isn't very useful, but still... it works! |
|||
|
09 Apr 2009, 15:47 |
|
|
buzzkill 09 Apr 2009, 16:46
Glad to hear you get some use out of it
|
|||
|
09 Apr 2009, 16:46 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|