I have created a separate include files for general purpose uses in my assembly programs. (such as string operations / formatted input/etc.)
When i include those files i notice all of the functions get included in the target binary file.
Is there way I can manage to include only the used functions(like using include files in C/C++ library files)?
I'm using MASM and targeting x86.
To extract separate functions from an object file, the linker needs to know where each one starts and where it ends. It can't reliably tell that from the assembly, so you need to help it.
A common way is to put each function into a separate file and assemble them like that; this way the linker can include or exclude each object file independently. This is the simplest way and works with most assemblers, not just MASM, so I'd recommend trying it.
Another way could be to put each function into a separate segment; the MS linker can exclude unused segments but only if they're marked as so-called "COMDAT" (communal data). Unfortunately, MASM does not support setting this attribute.
There have been some work on adding this info to the OBJ file as a post-processing step, but unfortunately the archive with the tool seems to be gone from the Internet:
Function level linking with MASM
Additional links:
How to achieve "function level linking" with MASM? (includes a tool for semi-automated splitting into several files).
flat assembler - COMDAT support
MSDN forums - Comdat
JWASM:
Support for COFF COMDATs
The last link mentions "Support for COMDAT is added in jwasm v2.10."
Related
I've been experimenting with loading functions from the Windows system DLLs using only the loader functions exported by NTDLL. This works as expected. For the sake of curiosity and getting an even better understanding of the process structure in NT-based systems, I've started trying to load functions from NTDLL by doing the following steps:
Load the PEB of the process from gs:[60h]
Iterate over the modules loaded into the process according to the loader to find NTDLL's base address
Parse the PE headers of NTDLL
Try to parse the export table to find LdrLoadDll, LdrGetDllHandle, and LdrGetProcedureAddress
This fails at step 4. After stepping through it in a debugger (both VS2019 and WinDbg Preview), it seems as though the offsets I've tried yield an invalid structure that leads to an access violation when my code compares the current function name to one of the ones I'm searching for. My code is being compiled and run on a 64-bit copy of Windows 10 Pro build 21364. Note that I'm using my own header that contains definitions for the structures used for this (these definitions are from winnt.h and here) because the Windows headers don't really play nice with the rest of my code. The function trying to do this is here. For the record, this is part of an attempt to implement my own libc (again, for the sake of curiosity). The code that calls the functions is here. Any help with this is tremendously appreciated.
Nevermind, turns out I had outdated verbose definitions of the structures I was using. I found better (more up-to-date) definitions at https://vergiliusproject.com.
I am creating a MATLAB package using object-oriented programming. I have documented my classes according to a tutorial from MathWorks website. This standard of documentation, however, only works for doc and help commands, but not when I use publish. For example, properties, which have their description written in front of their declaration, don't have said declaration exported to HTML. There is no list of properties or methods at the beginning of the file, so that users can quickly skip to those. Lastly, documentation has to be read directly from the comments in the code, instead of being parsed to HTML.
When I try to add some HTML documentation inside my classes to publish them, the code also appears on doc and help, which is an undesired behavior. Is there a way to create class documentation so that properties and methods can be published to the Web? I've had experience with doc generators like Sphinx (Python) and Doxygen (many languages), in which the descriptions of classes, methods and properties are parsed to HTML so they can be published in places like Read the Docs or GitHub Pages so I am curious to know if MATLAB has something like that.
You can give a try to MTOC++ which uses Doxygen, therefore produces the standard Doxygen HTML documentation.
I have used it already to generate source code documentation for Matlab project containing standard Matlab functions, old class definitions with # notation and classes defined by classdef mixed, and it worked after some tailoring.
This somewhat larger project allows to create documentation for MatLab
files and classes (including packages) using a doxygen filter named
mtoc++. Moreover, a tool/class named MatlabDocMaker allows to create
the documentation from within MatLab. For Windows, Mac and Unix!
You can find it also on Mathworks File Exchange and you can find the documentation here.
One widely-used way to provide HTML documentation for MATLAB functions/class is the M2HTML project. It will automatically generate HTML documentation complete with dependency graphs, source code, and syntax highlighting.
Since my experience with HTML is fairly rudimentary (and pretty old), I am not sure if my requirement is realistic.
Lets say that I have quite a few files containing Lua source-code, and all of them have the ".lua" extension and available in a particular subdirectory. What I'd like to do is create a static index.html file, which when loaded in a browser, would show the list of the lua source-code files in a drop-down. Once one of the source-code files is selected, I'd like that the file gets loaded into an "area" on the same page, and is pretty-printed, i.e. with syntax-highlighting in browser. I was wondering if I could use something like the google-code-prettyfy for the syntax-highlighting part ? Also, I am not clear if an external lua sourcecode file can be loaded, and displayed within a certain region of html page as being rendered. If yes, would appreciate elaboration on the how part.
A tool like LDoc can be used to accomplish a lot of what you want, much as Doxygen would be used for a C language source kit.
Both are heavily driven by inclusion of specially formatted comments that carry documentation.
I know Doxygen can fold source code into the generated document set, I don't recall about LDoc. Both are actively under development.
It isn't necessarily a bad idea to use both tools on a project, especially if you have C source code implementing Lua modules. You could use Doxygen to build the overall document tree for your engine and C modules, and LDoc to build documentation of the Lua parts. It should be possible with a little care and configuration of both tools to get them to play well together.
I have a parameter and, on F4, we can choose the directory. I'm trying to figure out how to choose a folder and read the content of all the files in it (the files are in .CSV) to an internal table. I think I have to use TMP_GUI_DIRECTORY_LIST_FILES function. Hope I'm explaining myself. Thank you.
You'll have to do this manually: first read the list of files, the go through each file and process its contents. There may be some odd function modules to read CSV files, but be aware that many of them are broken - for example, they just clip the lines that exceed a certain length. Therefore I won't recommend any of them - personally, I'd implement the CSV import part myself.
If you have access to the transaction KCLJ in your system you could analyze the coding behind it. This tool has an option to interpret CSV files so you might find interesting function modules that might help you with your tasks.
EDIT: I looked at it very quickly and the piece of coding you could reuse is reconvert_format from include RKCDFILEINCFOR. An example how to call it is located starting from line 128 in the same include.
I'm having trouble finding good advice and common practices for the use of namespaces in Clojure. I realize that namespaces are not the same as Java packages so I'm trying to tease out the conventions in Clojure, which seem surprisingly hard to determine.
I think I have a pretty good idea how to split functions into clj files and even roughly how I'd want to organize those files into directories. But beyond that I'm having trouble finding the mechanics for my dev environment. Some inter-related questions:
Do I use the same uniqueness conventions for Clojure namespaces as I would normally use for Java packages? [ie backwards-company-domain.project.subsystem]
Should I save my files in a directory structure that matches my namespaces? [ala Java]
If I have multiple namespaces, do I need to compile all of my code into a jar and add it to my classpath to make it accessible?
Should each namespace compile to one jar? Or should I create a single jar that contains clj code from many namespaces?
Thanks...
I guess it's ok if you think it helps, but many Clojure projects don't do so -- cf. Compojure (using a top-level compojure ns and various compojure.* ns's for specific functionality), Ring, Leiningen... Clojure itself uses clojure.* (and clojure.contrib.* for contrib libraries), but that's a special case, I suppose.
Yes! You absolutely must do so, or else Clojure won't be able to find your namespaces. Also note that you musn't use the underscore in namespace names or the hyphen in filenames and wherever you use a hyphen in a namespace name, you must use an underscore in the filename (so that the ns my.cool-project is defined in a file called cool_project.clj in a directory called my).
You need to make sure all your stuff is on the classpath, but it doesn't matter if it's in a jar, multiple jars, a mixture of jars and directories on the filesystem... As long as it obeys the correct naming conventions (your point no. 2) you should be fine.
However, do not compile things ahead-of-time if there's no particular reason to do so -- this may prevent your code from being portable across various versions of Clojure without providing any benefits besides a slightly improved loading time.
You'll still need to use AOT compilation sometimes, notably in some Java interop scenarios -- the documentation of the relevant functions / macros always mentions that. There are examples of things requiring AOT in clojure.contrib; I've never needed it, so I can't provide much in the way of details.
I'd say you should use jars for functional units of code. E.g. Compojure and Ring get packaged as single jars containing many namespaces which together compose the whole package. Also, clojure.contrib is notably packaged as a single jar with multiple unrelated libraries; but that again may be a special case.
On the other hand, a single jar containing all of your project's code together with its dependencies might occasionally be useful for deployment. Check out the Leiningen build tool and its 'uberjar' facility if you think that sort of thing may be useful to you.
Strictly speaking, not necessary, though many Java projects have dropped that convention as well, especially for internal projects or private APIs. Do avoid single-segment namespaces though, which would result in classfiles being generated in the default package.
Yes.
Regarding 3 & 4, packaging and AOT compilation are entirely orthogonal to the question of namespace conventions.