Where is the definition of function copyout() in FreeBSD for AMD64?
(http://www.unix.com/man-page/FreeBSD/9/copyout/)
The only place I can find is in sys/sys/systm.h.
The definition/declaration is:
int copyout(const void * __restrict kaddr, void * __restrict udaddr,
size_t len) __nonnull(1) __nonnull(2);
Is it a declaration or a definition? What does __nonnull(1) and __nonnull(2) mean?
That is a function prototype, otherwise known as a declaration. The implementation (definition if you choose) is in the kernel sources. You can find those online, or (if you chose to install sources) on your local FreeBSD machine (under /usr/src/sys). There are actually several copies, depending on the hardware for which the kernel is compiled. (The function names, by the way, are "old" — I encountered them in the mid-1980s, and they were well-known at that point in time).
The kernel source contains several implementations of these functions, depending on the hardware platform. For instance, in FreeBSD 10, the amd64 version is written in assembly language (see SVN in /usr/src/sys/amd64/amd64/support.S for instance). In the same release, I found only one implementation written in C (under the powerpc subtree), and in current source, that has been rewritten. So, to know "where" is the source, you must do some research and find the corresponding source for your hardware platform and release of FreeBSD.
__nonnull is a compiler directive telling it to ensure that the given parameters are not obviously null-pointers. See for example these mailing list comments:
svn commit: r283249 - head/sys/sys
Introduce the gcc/clang nonnull attribute in the signal and pthread headers.
Related
I am writing a compiler targeting the common intermediate language and want to use .data-declarations for globals. I mean section II.16.3.1 of the Spec.
How can I use what is described as "Address of label"? The following does assemble using .NET-Core's ilasm:
.assembly extern mscorlib
{
.ver 4:0:0:0
}
.assembly 'string'
{
}
.module 'string'
.data hello_world_data = { int8(72), int8(101), int8(108), int8(108), int8(111), int8(32), int8(87), int8(111), int8(114), int8(108), int8(100), int8(33), int8(0) }
.field static int8 hello_world at hello_world_data
.data addr_of_data = &(hello_world_data)
.field static int8* hello_world_ptr at addr_of_data
.method public static default int32 main () cil managed {
.entrypoint
ldc.i4.0
ret
}
But when I try to execute the code above, I get the following error message (using .NET-Core on Linux):
Unhandled exception. System.BadImageFormatException: Could not load file or assembly '/home/lou/uni/proj/stuff/tests/test-global-arrays/string.exe'. An attempt was made to load a program with an incorrect format.
File name: '/home/lou/uni/proj/stuff/tests/test-global-arrays/string.exe'
[1] 12019 abort (core dumped) dotnet string.exe
Any ideas/help?
If this is important for you, I would suggest filing an issue in the https://github.com/dotnet/runtime repo.
I assume the reason this doesn't work outside Windows is because these directives generate data with relocations (places within the executable that need to be fixed up with a real address once the executable is loaded into memory). Since the format of the executables in .NET is based on the Windows PE format, the relocation is processed by Windows when it loads the executable.
Outside Windows, CoreCLR ships with a small "Windows loader emulator" that loads the .NET executables the way Windows would load them. But it probably misses the handling for these relocations. The IL format doesn't generate relocations otherwise.
But these relocations are going to be problematic in many places (I fully expect e.g. tools like the IL Linker to miss them and damage them, I assume Mono doesn't have handling for the these either, they are going to be problematic for AOT compilation, etc.).
While doing catkin_make ROS_MRPT_SLAM, I got following error
In file included from /usr/include/mrpt/base/include/mrpt/utils/CFileGZInputStream.h:12:0,
from /home/ian/catkin_ws/src/mrpt_slam/mrpt_ekf_slam_2d/include/mrpt_ekf_slam_2d/mrpt_ekf_slam_2d.h:11,
from /home/ian/catkin_ws/src/mrpt_slam/mrpt_ekf_slam_2d/src/mrpt_ekf_slam_2d.cpp:7:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h: In member function ‘void mrpt::utils::CStream::WriteVariant(T)’:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h:313:15: error: use of ‘auto’ in lambda parameter declaration only available with -std=c++14 or -std=gnu++14
t.match([&](auto& o) { this->WriteObject(o); });
^
/usr/include/mrpt/base/include/mrpt/utils/CStream.h: In lambda function:
/usr/include/mrpt/base/include/mrpt/utils/CStream.h:313:45: error: no matching function for call to ‘mrpt::utils::CStream::WriteObject(int&)’
t.match([&](auto& o) { this->WriteObject(o); });
I guess it's compatibility matter or something because there were missing header files and so on.
This is the ROS_PACKAGE wiki: http://wiki.ros.org/mrpt_slam
And I just followed instruction from official MRPT website.
If the developer or anyone who is familiar with mrpt toolkit sees this question, may I get some advice about these errors?
By the way, I installed mrpt toolkit using the following website's instruction: http://www.mrpt.org/MRPT_in_GNU/Linux_repositories.
I'm the main author of MRPT and of part of the ROS packages.
Sorry for the mess, but you found us in the transition between the mrpt series 1.5.* and a new mayor rewrite based on C++14 which currently is published in git as mrpt 1.9.9 and eventually will be released as 2.0.0.
This transition must be propagated to the ros nodes, but so far we have upgraded mrpt_navigation only, mrpt_slam is in the to-do list.
So: a solution is to install an mrpt version of the 1.5.* series, and to build the ros packages from sources, paying attention to checking out the branches named compat-mrpt-1.5.
Hope this helps!
I've found the sbt-groovy plugin and it properly compiles both the test and the main sources just fine. However, the definedTests key is always empty; SBT never discovers any groovy tests. I've verified this with a very simple single src/test/groovy/Test.groovy with a single method annotated #Test which should be picked up by the junit-interface.
I think the root of the issue is that the sbt-groovy plugin needs to define the task "definedTests" in its own plugin source code. This task provides a Seq[TestDefinition].
Looking at how SBT itself populates the sequence reveals it uses additional output from the scala compiler (which also happens to compile java files, so it works out of the box for java) in an Analysis class which is populated by output from the IncrementalCompiler
I've fiddled around with the taskdef, but I'm not sure I'm even on the right path. Documentation on this stuff is pretty sparse, or heavily connected to the IncrementalCompiler.
What code do I need in sbt-groovy to produce a Seq[TestDefinition] that satisfies SBT so that I can run tests (picked up by the junit-interface) that are written in Groovy?
The test detection code is in Tests.discover, which you might be interested in.
It seems like all you need is the list of methods with annotations and list of subclasses.
If you have some way of finding them out, you probably could mimic what's going on in the code.
The discovery code, as you mentioned, relies on the the Analysis datatype, which is the inner gut of
the incremental compiler. You might be able to take advantage of the fact that it is
sbt (not Scala or Java compiler) that is responsible for incremental compilation.
For Java compilation, AnalyzingJavaCompiler.compile calls the compiler and then does the analysis.
In theory, you could define an AnalyzingGroovyCompiler that uses the same mechanism
as the one used for the Java compilation. This is not exactly a walk in the park since
some of the parts are hidden behind private[sbt].
Long story short, I put together a hacky proof-of-concept that wrangles the incremental compiler into generating Analysis for Groovy code, and was able to detect a test.
https://github.com/eed3si9n/sbt-groovy-test
I've only tested with one simple use case
import org.junit.Test
import org.junit.Assert
class Foo {
#Test
public void foo() {
Assert.assertEquals(1, 2)
}
}
Running test from sbt yeilds the following output:
> test
[info] Start Compiling Test Groovy sources : /Users/xxx/sbt-2167-groovy/src/test/groovy
[error] Test Foo.foo failed: expected:<1> but was:<2>, took 0.062 sec
[error] Failed: Total 1, Failed 1, Errors 0, Passed 0
[error] Failed tests:
[error] Foo
[error] (test:test) sbt.TestsFailedException: Tests unsuccessful
[error] Total time: 1 s, completed Aug 23, 2015 5:05:01 AM
It might not work with future versions of sbt. Caveat emptor.
I am am unable to get avr-elf-windows and WinAVR to work. I have managed to build the example supplied with avr-elf-windows (ATmega2560). But if I try and expand to use another chip or start using the WinAVR supplied packages and projects I keep getting errors I cannot work out.
Method 1:
Modify the ATmega2560 example to use the WinAVR packages.
Changed:
with Atmega2560; use Atmega2560;
to:
with AVR; use AVR;
with AVR.Atmega328p; use AVR.atmega328p;
Create a project file to include:
with "C:\WinAVR-20100110\lib\gnat\avr.gpr";
with "C:\WinAVR-20100110\lib\gnat\avr_app.gpr";
Running make I get the following error:
avr-gnatmake: "C:\WinAVR-20100110\lib\gnat\avr_lib\avr-int_img.adb" compilation error
Great, I have a compilation issue, but I cannot see the error.
Method 2:
Open the above project file in GPS. Change the build setting to be gnatmake. GPS now starts reporting errors and warnings:
Project warning: object directory "avr_lib/avr5/obj" not found
Project library directory "C:\WinAVR-20100110\lib\gnat\avr_lib\avr5\lib\" does not exist
The latter issue is very clearly the fact that I have not set up GPS correctly to tell it the values of microcontroller and architecture, but I cannot seem to find anything to resolve this.
Method 3:
To use the WinAVR set up directly using makefiles which then gives me the error:
avr-gnatmake: RTS path not valid: missing adainclude and adalib directories
If I follow the instructions I can find by searching the web I can only find details for building the required libraries under Linux.
Platform: Windows 7.
With the combination of the two answers above I have now managed to link my sample code. As to wether it will work on the Arduino, that is a different issue.
Many thanks for the help.
I have found it a bit frustrating to get this far, and I wonder if there are others out there who may just give up on Ada on the Arduino and go back to the Arduino IDE and therefore missing out on the opportunity to learn a language with more structure. There are many misleading pages out there that also do not help.
You might want to take a look in the paper Integrating 8-bit AVR Micro-Controllers in Ada. Basically you can use a GPS project file arduino.gpr like
project Arduino is
for Source_Dirs use (".", "src");
for Object_Dir use "obj";
for Exec_Dir use "bin";
for Main use ("main.adb");
package Compiler is
for Default_Switches ("ada") use ("-mmcu=avr5");
end Compiler;
package Ide is
for Gnat use "avr-gnat";
for Gnatlist use "avr-gnatls";
for Debugger_Command use "avr-gdb";
end Ide;
package Builder is
for Executable_Suffix use ".elf";
for Default_Switches ("ada") use ("--RTS=rts-zfp");
end Builder;
package Linker is
for Default_Switches ("ada") use ("obj\crtm328p._o", "-nostdlib", "-lgcc", "-mavr5", "-Tdata=0x00800200", "-mmcu=avr5");
end Linker;
end Arduino;
and you can code a spec for your ATmega328P like
with Interfaces; use Interfaces;
with System;
package ATmega328P is
-- PORTB: Port B Data Register
PORTB : Unsigned_8;
for PORTB'Address use System'To_Address (16#25#);
-- DDRB: Port B Data Direction Register
DDRB : Unsigned_8;
for DDRB'Address use System'To_Address (16#24#);
-- PINB: Port B Input Pins
PINB : Unsigned_8;
for PINB'Address use System'To_Address (16#23#);
end ATmega328P;
to be imported by your main file or libraries.
Bear with me if this isn't the immediate answer; I have only used the AVR-Ada toolchain on Linux, so we may have to iterate towards a solution unless someone else spots the problem first.
The first thing to decipher is which version of the AVR-Ada tools you have:
your project file USED to need (using avr-ada 1.1)
with "C:\WinAVR-20100110\lib\gnat\avr.gpr";
Now with avr-ada 1.2.1 you need (instead)
with "C:\WinAVR-20100110\lib\gnat\avr_app.gpr";
for building applications, and <same path>/avr_lib.gpr for libraries.
I don't believe you ever need both! And they may conflict with each other.
I don't know the state of the Windows binary build, but if you need the latest version (recommended : it's a real improvement) you may need to build it from source.
Method 1 : were you running Make from a command line? If so, I would expect to see errors in all their gory details.
Method 2 : can't help you here, I don't know GPS well enough. However I can say that on Linux there are no "avr5" folders in [wherever]/avr/lib/gnat/avr_lib. (AVR5 is correct for the 328p)
Instead there IS a [wherever]/avr/lib/avr5 containing libc and other C-related objects - including the crtm328p.o that Rego names in his linker switches, and a [wherever]/lib/gcc/avr/4.7.2/avr5 folder containing libgcc.a. You probably need to find the former and point GPS at it...
Method 3 : This looks the easiest to fix. The "gnatmake" command needs an --RTS= option pointing at the correct RTS for the 328p. This should be --RTS=rts/avr5 assuming the RTS is correctly installed.
Alternatively a full path ought to work. Here, that would be
--RTS=/opt/avr_472_gnat/lib/gcc/avr/4.7.2/rts/avr5
on Windows you may have to poke around to find the correct path.
Using Method 1 this --RTS option is automatically generated by avr_app.gpr.
It appears that having a mix of 3 or 4 tool chains installed that provide one of aspects of WinAvr, AvrAda causes significant problems (these included WinAvr, Avr-Ada, Cygwin, AVR compiler by Adacore and MinWG).
Starting with a brand new Win7 or Win8 installation perform the following:
Install WinAVR-20100110 to C:\WinAVR-20100110
Copy the content of the Avr-Ada-1.2.0_bin to C:\avr-ada-1.2.0
Add C:\avr-ada-1.2.0\bin to the PATH
Compiling the content of each of the examples in C:\avr-ada-1.2.0\share\doc\avr-ada\apps identifies that some DLLs are missing: libiconv-2.dll, libgmp-10.dll, libmpc-2.dll, libmpfr-1.dll
These can be found in a MinGW installtion.
Create a virtual machine to install MinGW on, in order to ensure it did not mess with the main PC.
Copy the missing DLLs in C:\WinAVR-20100110\bin
The example in DS1820 will not compile due to crc_lib being missing.
In order to upload to the Arduino the makefiles must be modified for your local installation, board type etc.
Is it possible to debug core file generated by a executable compiled without gdb flag ?
If yes, any pointers or tutorials on it ?
Yes you can. It will not be easy though. I will give you an example.
Lets say that I have the following program called foo.c:
main()
{
*((char *) 0) = '\0';
}
I'll compile it and make sure that there is no symbols:
$ cc foo.c
$ strip a.out
$ file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped
Ok, time to run it:
$ ./a.out
Segmentation fault (core dumped)
Oops. There seems to be a bug. Let's start a debugger:
$ gdb ./a.out core
[..]
Reading symbols from /tmp/a.out...(no debugging symbols found)...done.
[..]
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804839c in ?? ()
(gdb) bt
#0 0x0804839c in ?? ()
#1 0xb7724e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#2 0x08048301 in ?? ()
Hmm, looks bad. No symbols. Can we figure out what happened?
(gdb) x/i $eip
=> 0x804839c: movb $0x0,(%eax)
Looks like it tried to store a byte with a value of zero to the memory location pointed by the EAX register. Why did it fail?
(gdb) p $eax
$1 = 0
(gdb)
It failed because the EAX register is pointing to a memory address zero and it tried to store a byte at that address. Oops!
Unfortunately I do not have pointers to any good tutorials. Searching for "gdb reverse engineering" gives some links which have potentially helpful bits and pieces.
Update:
I noticed the comment that this is about debugging a core dump at a customer. When you ship stripped binaries to a customer, you should always keep a debug version of that binary.
I would recommend not stripping and even giving the source code though. All code that I write goes to a customer with the source code. I have been on the customer side too many times facing an incompetent vendor which has shipped a broken piece of software but does not know how to fix it. It sucks.
This seems to be actually a duplicate of this question:
Debug core file with no symbols
There is some additional info there.
Yes, you can,
this is what people who i.e. write cracks are doing,
unfortunately i don't have the slides and documents of a course i followed at university anymore, but googling for reverse engineering or disassembly tutorials will give you some starting points. Also knowing your way around in assembly code is essential.
Our class was based on a book mainly chapter 1 & 3 but there is a new edition out now
Computer Systems: A programmer's perspective by R.E. Bryant and D.R. O'Hallaron
which explains the basics behind computer systems and also gives you good knowledge of the working of programs in systems.
Also when learning this be aware that 64bit cpus have different assembly code than 32bit cpu's, just in case.
If the program is compiled without -g flag,you cannot debug core file.
Otherwise you can do so as:
gdb executable corefile
More you can find at:
http://wwwpub.zih.tu-dresden.de/~mlieber/practical_debugging/04_gdb.pdf