I Just jumped into the Linux kernel Code and my goal is to submit some trivial patches.I want to use Smatch [ http://smatch.sourceforge.net/ ] but I'm not getting how to use it. Can any one write a tutorial or point me to one.
Related
For work purposes I need to link against an object file generated by another program and found in its folder, the case is that I did not find information about this kind of linkage. I think that if I hardcode the paths and put the name-of-obj.o in front of the package_LDADD variable should work, but the case is that I don't want to do it that way.
If the object is not found I want the configure to fail and tell the user that the name-of-obj.o is missing.
I tried by using AC_LIBOBJ([name-of-obj.o]) but this will try to find in the root directory a name-of-obj.c and compile it.
Any tip or solution around this issue?
Thank you!
I need to link against an object file generated by another program and
found in its folder
What you describe is a very unusual requirement, not among those that the Autotools are designed to handle cleanly or easily. In particular, Autoconf has no mechanisms specifically applicable to searching for bare object files, as opposed to libraries, and Automake has no particular automation around including such objects when it links. Nevertheless, these tools do have enough general purpose functionality to do what you want; it just won't be as tidy as you might like.
I think that if I hardcode the paths and put the
name-of-obj.o in front of the package_LDADD variable should work, but
the case is that I don't want to do it that way.
I take it that it is the "hardcode the paths" part that you want to avoid. Adding an item to an appropriate LDADD variable is not negotiable; it is the right way to get your object included in the link.
If the object is not found I want the configure to fail and tell the
user that the name-of-obj.o is missing.
Well, then, the key thing appears to be to get configure to perform a search for your object file. Autoconf does not have a built-in mechanism to perform such a search, but it's just a macro-based shell-script generator, so you can write such a search in shell script + Autoconf, maybe something like this:
AC_MSG_CHECKING([for name-of-obj.o])
OTHER_LOCATION=
for my_dir in
/some/location/other_program/src
/another/location/other_program.12345/src
$srcdir/../relative/location/other_program/src; do
AS_IF([test -r "${my_dir}/name-of-obj.o"], [
# optionally, perform any desired test to check that the object is usable
# ... perhaps one using AC_LINK_IFELSE ...
# if it passes, then
OTHER_LOCATION=${my_dir}
break
])
done
# Check whether the object was in fact discovered, and act appropriately
AS_IF([test "x${OTHER_LOCATION}" = x], [
# Not found
AC_MSG_RESULT([not found])
AC_MSG_ERROR([Cannot configure without name-of-obj.o])
], [
AC_MSG_RESULT([${OTHER_LOCATION}/name-of-obj.o])
AC_SUBST([OTHER_LOCATION])
])
That's functional, but of course you could embellish, such as by providing for the package builder to specify a location to use via a command-line argument (AC_ARG_WITH(...)). And if you want to do this for multiple objects, then you would probably want to wrap up at least some of that into a custom macro.
The Automake side is much less involved. To get the object linked, you just need to add it to the appropriate LDADD variable, using the output variable created by the above, such as:
foo_LDADD = $(OTHER_LOCATION)/name-of-obj.o
Note that if you're building just one program target then you can use the general LDADD instead of foo_LDADD, but note that by default these are alternatives not complements.
With that said, this is a bad idea overall. If you want to link something that is not part of your project, then you should get it from an installed library. That can be a local, custom-built library, of course, so long as it is a library, not a bare object file, and it is installed. It can be a static library if you don't want to rely on or distribute a separate shared library.
On the other hand, if your project is part of a larger build, then the best approach is probably to integrate it into that build, maybe as a subproject. It would still be best to link a library instead of a bare object file, but in a subproject context it might make sense to use a lib that was not installed to the build system. In conjunction with a command-line argument that tells it where to find the wanted lib, this could make the needed Autoconf code much cleaner and clearer.
I wanna add custom helloworld syscall to FreeBSD. I used following link as my guide: http://members.tripod.com/s_mathur/bsdhowto.html In step 4 says: Modify the Make File to include sys_hello.c , etc and recompile the kernel! Which Make File? Where is it? and how to compile it and how call syscall hello?
The error that I faced with it, is:
init_sysent.o:(.data + 0x6638): undefined reference to 'sys_hello'
I think that it is because of my Make file, because I don't know I should modify which Make File.
I'm afraid you are not ready to do any kernel development and as such strongly suggest you refrain from it.
I don't know how you ended up on that guide, I have trouble finding it when I look for ways to add system calls to the FreeBSD kernel.
The guide has bits which are outdated and some which were always wrong.
You created a new file (sys_hello.c) but did not add it to the build process. Figuring out how to do that should be trivial.
1. pick a syscall which is always provided, like fork
2. find the file implementing it
3. grep the source tree for mentions of that file
4. profit
Performing the steps and getting the answer is left as an exercise for the reader.
int syshello(p, uap)
struct proc* p; struct syshello_args uap;
K&R C declaration? Just how old is this?
The first argument for several years now is struct thread *.
{
sprintf(uap->buf,"Hello"); /* fill the buffer with Hello */
Fundamentally wrong. Consider what happens if userspace passes a kernel address. Also this assumes shared address spaces to "work". The code should have used copyout. Except the code is additionally wrong by not having an argument allowing the userspace to say what the size is.
p->p_retval[0] = 0; /* set the return value of the system call*/
return 0;
}
As noted earlier, given your difficulty with figuring out what to do with the new file it is clear you are new to programming and as such you really should not touch the kernel until you grow.
I have a list called list_ds of a custom-defined data structure in my OCaml source. I compiled the source for debugging and ran the debugger halting execution of my code at a breakpoint. Now I want to check particular element of the data structure within the list. If I use the print list_ds command in the debugger, I see [ abstr; abstr; abstr; abstr; <abstr>; ...] - list with word abstr. If I use "print list_ds.(0)" command in the debugger, it tells me that $1 : ds = abstr. But I really want to see the elements of the ds data structure at the first location in the list_ds. How can I do that?
One option would be to install your own custom print function for the type. This is described in Section 16.8.8 of the OCaml Debugger Manual.
A downside of this approach is that it requires quite a bit of setup, especially since the output must be done through the Format module. You might be able to use the deriving project to speed this up. It can generate formatting functions automatically.
I understand that over a thousand built-in rewrite rules in Mathematica populate the global rules table by default. Is there any way to get Mathematica to give a full or even partial list of those rules?
The best way is to get a job at Wolfram Research.
Failing that, I think that for things not completely compiled into the kernel you can recover most of the rules/definitions. Look at
Attributes[fn]
where fn is the command that you're interested in. If it returns
{Protected, ReadProtected}
then there's something you can get a look at (although often it's just a MakeBoxes (formatting) definition or a AutoLoad/Stub type definition). To see what's there run
Unprotect[fn];
ClearAttributes[fn, ReadProtected];
??fn
Quite often you'll have to run an example of the command to load it if it was a stub. You'll also have to dig down from the user-facing commands to the back-end implementations.
Eventually you'll most likely reach a core command that is compiled into the kernel that you can not see the details of.
I previously mentioned this in tips for creating Graph diagrams and it got a mention in What is in your Mathematica tool bag?.
An good example, with a nice bite-sized and digestible bit of code is Experimental`AngularSlider[] mentioned in Circular/Angular slider. I'll leave it up to you to look at the code produced.
Another example is something like BoxWhiskerChart, where you need to call it once in order to load all of the code. Then you see that BoxWhiskerChart proceeds to call Charting`iBoxWhiskerChart which you'll have to unprotect to look at, etc...
Below is a small screenshot from within RubyMine 3.1. I am just starting to learn Ruby. The code here is from the Presenter-First MVP C# code generator over at atomicobject.com.
I am using this project along with a book to learn Ruby. The documentation for puts shows that it expects at least one parameter. Yet this code appears "somewhat legal" for two reasons:
The code appears to work fine when I
step thru it via the debugger.
Searching online, and even here at SO, shows that puts w/o arguments creates a newline.
However, is it bad practice to do this (hence the RubyMine warning)? The code I am looking at is from 2006. I'm running it with Ruby 1.9.2 if that matters any.
This is perfectly fine, as puts provides 'default' value for the first parameter:
def puts(obj='', *arg)
As for RubyMine, it doesn't show any errors for me. May it happen that you define method puts somewhere else in your code? You can cmd+click on it, to get to the definition.
Anyway, if you're able to reproduce problem in a clean new project, you can freely submit a bug report to JetBrains.
No, it can be helpful to create the physical line break in your source as well as the output, and like you have seen already, puts is perfectly capable of accepting zero arguments.
Personally, if I'm creating a multi-line output I prefer to use here-doc syntax.