I'm trying to install FFMPEG to Kali Linux 2.0
So far I've been trying to use the following commands:
git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg
cd ffmpeg
./configure
make
make install
However when I try and make it I get the following errors:
libavcodec/x86/imdct36.asm:393: error: operation size not specified
library.mak:30: recipe for target 'libavcodec/x86/imdct36.o' failed
make: *** [libavcodec/x86/imdct36.o] Error 1
I'm really stumped as how to resolve this as my skill are only moderate...
I came across the answer just by chance, but
I needed to install YASM before compiling...
apt-get install yasm
this particular problem took a lot of tracking down, due to the large numbers of macros in the source. line 393 reads:
DEFINE_IMDCT
and looking for that macro, we find it at line 179. but it has numerous instructions in it, and conditionals, and any one of those could be the culprit. so first what we do is make V=1 to turn on verbose (normal) GNU make output. then we see:
jcomeau#aspire:~/rentacoder/jcomeau/floureon/ffmpeg$ nasm -f elf -DPIC -g -F dwarf -I./ -I.// -Pconfig.asm -I libavcodec/x86/ -o libavcodec/x86/imdct36.o libavcodec/x86/imdct36.asm
we change that to:
jcomeau#aspire:~/rentacoder/jcomeau/floureon/ffmpeg$ nasm -l /tmp/imdct36.lst -f elf -DPIC -g -F dwarf -I./ -I.// -Pconfig.asm -I libavcodec/x86/ -o libavcodec/x86/imdct36.o libavcodec/x86/imdct36.asm
to get a listing file. looking into the listing for the operation size not specified error, we find it at line 102741, at level <4> of the macro expansion. scrolling up, we find the level 2 instruction at line 102668 as extractps [%3 + %4], %1, 1 and the level 1 instruction at line 102583, STORE m6, m7, outq + 16*SBLIMIT, 4*SBLIMIT.
so we go back to libavcodec/x86/imdct36.asm, search for STORE, and find it at line 145. sure enough, we find 3 extractps instructions under it:
extractps [%3 + %4], %1, 1
extractps [%3 + 2*%4], %1, 2
extractps [%3 + 3*%4], %1, 3
we change them to:
extractps dword [%3 + %4], %1, 1
extractps dword [%3 + 2*%4], %1, 2
extractps dword [%3 + 3*%4], %1, 3
assuming 32-bit operands. and sure enough, it finishes the build after that, without having to install yasm.
how do I know it shouldn't be qword instead? I don't, but it doesn't make sense, since extractps only uses 32 bit destinations: "Extract a single-precision floating-point value from xmm2 at the source offset specified by imm8 and store the result to reg or m32. The upper 32 bits of r64 is zeroed if reg is r64." (http://www.felixcloutier.com/x86/EXTRACTPS.html).
Related
I am trying to follow the exercise in the book PC Assembly by Paul Carter. http://pacman128.github.io/pcasm/
I'm trying to run the program from 1.4 page 23 on Ubuntu 18. The files are all available on the github site above.
Since original code is for 32bit I compile using
nasm -f elf32
for first.asm and asm_io.asm to get the object files. I also compile driver.c
I use the linker from gcc and run
gcc -m32 -o first first.o asm_io.o driver.o
but it keeps giving me a bun of errors like
undefined reference to '_scanf'
undefined reference to '_printf'
(note _printf appears instead of printf because some conversion is done in the file asm_io.asm to maintain compatibility between windows and linux OS's)
I don't know why these errors are appearing. I also try running using linker directly
ld -m elf_i386 -e main -o first -first.o driver.o asm_io.o -I /lib/i386-linux-gnu/ld-linux.so.2
and many variations since it seems that its not linking with the C libraries.
Any help? Stuck on this for a while and couldn't find a solution on similar questions
Linux doesn't prepend _ to names when mapping from C to asm symbol names in ELF object files1.
So call printf, not _printf, because there is no _printf in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf, Linux uses printf.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf and so on, but it requires you to manually define ELF_TYPE by assembling with nasm -d ELF_TYPE.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
I try to assemble and link my teacher's NASM code, but it does not work on my linux (Ubuntu 16.03) while it's working on her pc (Windows)
segment .data
a dw 10
segment .bss
segment .text
global _main:
extern _printf
_main:
_b100: mov eax, 10
_b150: mov eax, a
_b200: mov ebx, eax
fin:
ret
Those are the instructions i follow to assemble the code
nasm -g -f elf32 test.asm;ld -m elf_i386 -s -o demo *.o
ld returns an error
ld: warning: cannot find entry symbol _start; defaulting to 0000000008048080
Regardless the effect of errors the executable is generated every time I run the commands but when I want to execute breakpoints on the program with gdb I can't.
First the code needs some patching for linux:
-global _main:
+global main
-_main:
+main:
Remove the underscore from main symbol. Also in the global directive don't add the colon, that's needed when you specify new label.
The removal of underscore will apply also to other external symbols, like printf or when you will publish function from your asm to the C with global.
Compiling:
nasm -g -felf32 -Fdwarf test.asm; gcc -m32 -o demo test.o
And you need to have nasm, gcc and 32 bit libraries installed, not sure what is the minimal set of packages, but going by sudo apt-get install nasm gcc gcc-multilib may be enough even on clean install of *buntu.
The System calls like:
1 - exit
3 - read
4 - write
They work fine. However, calls like:
11 - execve
29 - pause
They do NOT work. I've tried using both hex and decimal (simply to make sure I wasn't messing up on that end). Please help!
Something simple:
SECTION .text
global _start
_start:
xor eax, eax
xor ebx, ebx
mov al, 29
int 80h
Here's how I'm compiling. I'm running x64 bit Arh Linux and compiling with NASM to emulate i386:
nasm -f elf32 -o temp.o file.asm
ld -s -m elf_i386 -o exec temp.o
rm temp.o
./exec
Rather than pausing or anything, I get nothing. It just stops (no, it's not pausing). I can type, I can hit enter, I can do whatever I want. Once I ctrl+c, it closes. But it's not a pause.
This appears to work for me on x86_64 Archlinux. How are you certain it's not pause()ing?
strace'ing for me indicates that pause() does get called and produces the same characteristics you described above. Sending a SIGHUP to that process from another terminal also resumes execution for me.
Please provide strace output.
I'm running on Ubuntu 12.10 64bit.
I am trying to debug a simple assembly program in GDB. However GDB's gui mode (-tui) seems unable to find the source code of my assembly file. I've rebuilt the project in the currently directory and searched google to no avail, please help me out here.
My commands:
nasm -f elf64 -g -F dwarf hello.asm
gcc -g hello.o -o hello
gdb -tui hello
Debug information seems to be loaded, I can set a breakpoint at main() but the top half the screen still says '[ No Source Available ]'.
Here is hello.asm if you're interested:
; hello.asm a first program for nasm for Linux, Intel, gcc
;
; assemble: nasm -f elf -l hello.lst hello.asm
; link: gcc -o hello hello.o
; run: hello
; output is: Hello World
SECTION .data ; data section
msg: db "Hello World",10 ; the string to print, 10=cr
len: equ $-msg ; "$" means "here"
; len is a value, not an address
SECTION .text ; code section
global main ; make label available to linker
main: ; standard gcc entry point
mov edx,len ; arg3, length of string to print
mov ecx,msg ; arg2, pointer to string
mov ebx,1 ; arg1, where to write, screen
mov eax,4 ; write command to int 80 hex
int 0x80 ; interrupt 80 hex, call kernel
mov ebx,0 ; exit code, 0=normal
mov eax,1 ; exit command to kernel
int 0x80 ; interrupt 80 hex, call kernel
This statement is false.
The assembler does produce line number information (note the -g -F dwarf) bits.
On the other hand he assembles what is obviously 32-bit code as 64 bits, which may or may not work.
Now if there are bugs in NASM's debugging output we need to know that.
A couple of quick experiments shows that addr2line (but not gdb!) does decode NASM-generated line number information correctly using stabs but not using dwarf, so there is probably something wrong in the way NASM generates DWARF... but also something odd with gdb.
GNU addr2line version 2.22.52.0.1-10.fc17 20120131, GNU gdb (GDB) Fedora (7.4.50.20120120-52.fc17)).
The problem in this case is that the assembler isn't producing line-number information for the debugger. So although the source is there (if you do "list" in gdb, it shows a listing of the source file - at least when I follow your steps, it does), but the debugger needs line-number information from the file to know what line corresponds to what address. It can't do that with the information given.
As far as I can find, there isn't a way to get NASM to issue the .loc directive that is used by as when using gcc for example. But as isn't able to take your source file without generating a gazillion errors [even with -msyntax=intel -mmnemonic=intel -- you would think that should work].
So unless someone more clever can come up with a way to generate the .loc entries which gives the debugger line number information, I'm not entirely sure how we can answer your question in a way that you'll be happy with.
This question already has answers here:
Assembling 32-bit binaries on a 64-bit system (GNU toolchain)
(2 answers)
Closed 6 years ago.
I have program written in 32 bit assembly language... Now I just can't compile it on 64 bit OS. On our school they are specific and program has to be written in 32 bit version. Here is my program:
bits 32
extern _printf
global _start
section .data
message db "Hello world!!", 10, 0
section .text
_start:
pushad
push dword message
call _printf
add esp, 4
popad
ret
Any idea? I have tried so many ways to compile that.
Error output after compiling:
nasm -f elf64 vaja4.asm
ld vaja4.o -o vaja4
./vaja4
output:
vaja4.o: In function `_start':
vaja4.asm:(.text+0x7): undefined reference to `_printf'
First change _printf to printf and the _start symbol to main, then use gcc to link the object file, which will automatically link it to libc, you need to do that because AFAIK you can't link to libc without a main. Also you should use elf32 not elf64 when assembling because the code has 32 bits instructions :
bits 32
extern printf
global main
section .data
message db "Hello world!!", 10, 0
section .text
main:
pushad
push dword message
call printf
add esp, 4
popad
ret
And build with:
nasm -f elf32 vaja4.asm
gcc -m32 vaja4.o -o vaja4
$./test
$Hello world!!
Edit:
Since you're now compiling 32-bit code on a 64-bit system, you will need to install the 32-bit version of the libraries
apt-get install ia32-libs
On Ubuntu 12.10, you need to install development packages first
sudo apt-get update
sudo apt-get install libc6-dev-i386
for
gcc -m32 vaja4.o -o vaja4
to work.
I doubt that the error you see is because of 32/64 bit issue. The error that you see i.e
vaja4.asm:(.text+0x7): undefined reference to `_printf'
is clearly telling you the symbol _printf is undefined which means that the library for printf function is not being linked.
your linking step i.e
ld vaja4.o -o vaja4
does not include any libraries. You need to link your program with a library that can provide definition of the printf function. I believe ld should pick the library it self without bothering you with these messages but because it is not able to find a suitable C library for this function, I guess you dont have the required libraries i.e either 32 bit or 64 library is missing.
Anyway, plz try the following sequence of commands to assemble and link your program:
nasm -f elf vaja4.asm
ld -m elf_i386 vaja4.o vaja4
./vaja4
It looks to me like you forgot to link against the C library, which is the part that provides the printf function (and others):
ld vaja4.o -o vaja4 -lc