NASM Forum > Example Code
Adjusting segments for linux linker commands and build files
Deskman243:
Good day everyone
I have noticed an increase of subjects on section use for NASM files. Coincidentally I've been mostly researching this as a quintiessential proof of concept program. For an overview we know that NASM offers a variety of file output options.
Previously I posted about the distinctions between making binary these file configurations. In this case I'm looking at the corresponding linux file commands for .bin files.
I have two types of model designs for review .
As a proof of concept here is the main design of a common linker path. The inferences here are majorly between the image preparation slightly changing the commands that can be observed from the figures below. Right now my question is about an adjustment for making these paths.
(1) File.img <= CAT file commands <= .bin files <= optional LD file commands <= optional elf type objects <= NASM assembling
(2) File.img <= DD file commands <= .bin files <= optional LD file commands <= optional elf type objects <= NASM assembling
Here are the corresponding build files.
(1) run2.sh
--- Code: ---
nasm -f bin -g -o boot2.bin boot2.asm
nasm -f elf -g stage1.asm -o stage1.o
nasm -f elf -g stage2.asm -o stage2.o
nasm -f elf -g stage3.asm -o stage3.o
nasm -f bin -g test2.asm -o test2.bin
nasm -f bin -g test3.asm -o test3.bin
nasm -f elf -g test2.asm -o test_2.o
nasm -f elf -g test3.asm -o test_3.o
nasm -f bin -g stage2.asm -o stage_2.bin
ld -g -m elf_i386 -Ttext 0x7e00 stage1.o -o stage1.bin --oformat binary
ld -g -m elf_i386 -Ttext 0x8000 stage2.o -o stage2.bin --oformat binary
ld -g -m elf_i386 -Ttext 0x8400 stage3.o -o stage3.bin --oformat binary
ld -g -m elf_i386 -Ttext 0xe600 test_2.o -o test_2.bin --oformat binary
dd if=/dev/zero of=os.bin bs=512 count=2828
cat boot2.bin \
stage1.bin \
stage2.bin \
stage3.bin \
test_2.bin \
test4.bin \
os.bin>os.img
rm -rf *\.bin
qemu-system-i386 -fda os.img
--- End code ---
(2) Makefile
--- Code: ---FILES =boot.o
FILES2 =stage3.o printstr.o
PROCURE = rm -rf
all: boot.bin stage1.bin test1.bin stage2.bin
dd if=boot.bin of=os.img bs=512 count=66 conv=notrunc
dd if=stage1.bin of=os.img bs=512 seek=1 conv=notrunc
dd if=test1.bin of=os.img bs=512 seek=10 conv=notrunc
dd if=stage2.bin of=os.img bs=512 seek=18 conv=notrunc
truncate -s 1M os.img
boot.o: boot4.asm
nasm -f elf -g -o boot.o boot4.asm
stage1.o: stage1.asm
nasm -f elf -g stage1.asm -o stage1.o
test1.o: test1.asm
nasm -f elf -g test1.asm -o test1.o
stage2.o: stage2.asm
nasm -f elf -g stage2.asm -o stage2.o
test2.bin: test2.asm
nasm -f bin -g test2.asm -o test2.bin
boot.bin: $(FILES)
ld -T link.ld $(FILES) -o boot.bin
stage1.bin: stage1.o
ld -g -m elf_i386 -T link2.ld stage1.o -o stage1.bin --oformat binary
stage2.bin: stage2.o
ld -g -m elf_i386 -T link4.ld stage2.o -o stage2.bin --oformat binary
test1.bin: test1.o
ld -g -m elf_i386 -Ttext 0x9000 test1.o -o test1.bin --oformat binary
clean:
$(PROCURE) *\.o
$(PROCURE) *\.bin
$(PROCURE) os.img
--- End code ---
Right now I'm trying to test the first program pathing however I have one major contestion. The "optional" part was for a graphical file that is very large. In fact I could only keep these file sizes when I use LD. However when I try to include other files past this I get weird readings from the file segments. Currently I'm trying to adjust a bug I found in my previous post concerning the path of the program here
Disk_Read(boot.asm) => Jump_From_Gate(Stage1.asm)
=>Jump_Into_BIOS16_Segment(Stage2.asm @ 0x8000)
=>test2.asm(data number fill pad @ 0x8200)
=>Stage3_Addressment( @ 0x8400)
If anyone else has found a similar thing I would be really happy to review this further. Otherwise I'll be available to correspond whenever I get these designs checked out.
Cheers!
Deskman243:
Revision 1
Here's a copy of the full source code for reference
Frank Kotler:
"xrm rfx" looks like a very dangerous command to me!
What's the story?
Frank
fbkotler
pig's tail
myfairpoint
dot
net
Deskman243:
Good news everyone
I got a patch in practice for the previous models. Apparently the BIOS Disk_Read functions coincidentally change addresses for the files larger than 512b. This takes care of the "optional" part of the model. I'll be adding a new revision once I pass the first round of test files.
--- Quote from: Frank Kotler on June 26, 2023, 03:00:58 PM ---"xrm rfx" looks like a very dangerous command to me!
What's the story?
Frank
fbkotler
pig's tail
myfairpoint
dot
net
--- End quote ---
Would you care to clarify this reference because I don't have any clue haha
Frank Kotler:
Hi Deskman.
Perhaps I am confused. No, I am definitely confused!
The referenced "dangerous command", or something like it. will delete everything on your system. It makes me inclined to ban you and your dog and the girl you took to the prom - forever! However I know you to be a legitimate poster... I hope... so I'm confused.
Further... "-f bin" makes sense, but "-g" doesn't do anything useful... I'm pretty sure.
"-f elf" does not make sense to me in this context... but you seem to use it successfully... I don't know how... So I'm confused on that, too.
You don't have to straighten me out. I can stay confused. But I got an email that this post had been "reported" which brought it to my attention. You might want to clarify that "dangerous command for me, at least.
Good luck, in any case!
Best,
Frank
Navigation
[0] Message Index
[#] Next page
Go to full version