Printing strings problem

[Grunt]

I found out that breaking at a specified address works better for me. That led me to another thing. This code:

Code: Select all

v.puts("X");

generates this:

Code: Select all

  1007ba:	68 44 88 04 08       	push   $0x8048844
  1007bf:	8d 45 d8             	lea    -0x28(%ebp),%eax
  1007c2:	50                   	push   %eax
  1007c3:	e8 de fe ff ff       	call   1006a6 <_ZN5Video4putsEPc>  

Could this mean that it's trying to access unreachable memory?

Code: Select all

Breakpoint 1, 0x001007c3 in main ()
(gdb) info registers
eax            0x103fd8 1064920
ecx            0x1      1
edx            0x3cc    972
ebx            0x2dae0  187104
esp            0x103fb0 0x103fb0
ebp            0x104000 0x104000
esi            0x5480d  346125
edi            0x5480e  346126
eip            0x1007c3 0x1007c3 <main+55>
eflags         0x200016 [ PF AF ID ]
cs             0x8      8
ss             0x10     16
ds             0x10     16
es             0x10     16
fs             0x10     16
gs             0x10     16
(gdb) x $eax
0x103fd8 <bss+8144>:    0x08048828

Both the parameters passed to the function are wrong - first the hardcoded value, then the value in eax, which again points to a wrong address. What should I do in this case?

[smeezekitty]

I had that problem, it means the linker does not know how to align your segments / offsets so its putting the string some where in memory but them reads it back from another location.

[Combuster]

I blame your linker script - you have circular address dependencies (LS_Data), and you are not specifying the link address for all sections.

You can grab a working linker script from the wiki - which has the same effect as yours probably intended to do.

[Grunt]

I had that problem, it means the linker does not know how to align your segments / offsets so its putting the string some where in memory but them reads it back from another location.

How did you fix it?

Here is an explanation, though it doesn't work for me. And for the last hour or so I keep modifying the linker script with no result.

[Solar]

You can grab a working linker script from the wiki - which has the same effect as yours probably intended to do.

If you ignore good advice given, at least give an indication why you're doing so. Otherwise one might get the impression that trying to help you is in vain...

[Grunt]

Sorry... I forgot to mention that. I did try the linker script provided there. Here's what I also tried:
- .rodata as a separate section, and inside .text
- with/without AT() for each section
- with/without the 4KB alignment
Also took a look at some other sample linker scripts I found that could help me, but I found nothing.

I'm running out of ideas...

[Combuster]

Since the linker script alone doesn't want to fix the problem, let's get back to the basics:
- OS and version
- Compiler + linker version
- All complete command lines and other operations used to build the final image.

[Solar]

@gravaera, thank you for your tips. My putch() is the same as the one in this example.

Including the global variables textmemptr, attrib, csr_x and csr_y? Including the supporting code? Did you initialize everything properly?

If you copy & paste other people's code, copy it exactly and make sure it works as-is, before starting to modify it.

[Grunt]

- OS and version
- Compiler + linker version
- All complete command lines and other operations used to build the final image.

1. Windows XP Service Pack 3
2.
gcc 3.4.6
gdb 6.8
binutils 2.19.1 (all three cross-compiled to target i586-elf)
nasm 2.07

Code: Select all

F:\osII>gcc -v
Reading specs from /usr/cross/lib/gcc/i586-elf/3.4.6/specs
Configured with: ./configure --target=i586-elf --prefix=/usr/cross --disable-nls --enable-languages=c,c++ --without-headers
Thread model: single
gcc version 3.4.6

F:\osII>nasm -v
NASM version 2.07 compiled on Jul 19 2009

F:\osII>ld -v
GNU ld (GNU Binutils) 2.19.1

F:\osII>gdb -v
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=i586-elf".

3.

Code: Select all

nasm -f elf32 loader.asm -o build/loader.o
set CFLAGS=-g -Wall -W -nostartfiles -nostdinc -nostdlib -fno-exceptions -fno-rtti -fno-builtin
set CINCLUDES=-I./include -I./include/kernel
g++ %CFLAGS% %CINCLUDES% -o build/main.o src/*.cpp
ld -T linker.ld -nostdlib -o build/kernel.bin
cd build
objdump --source -D -S -s kernel.bin > kernel.lst

This is how the linker script looks right now.

Solar: yes. I'm pretty certain the code is correct, because I can print single characters. The problem is because at runtime, the address of the string is not correct (it should be 0x100845). Perhaps a bug with GCC? I'll crosscompile a 4.4.x version soon, let's see if that works.

Thank you.

[Grunt]

No, that didn't work... I don't know what else to do.

When building with Cygwin, or MinGW, this doesn't happen. I tried with geezer's example.

100102: b9 00 10 10 00 mov $0x101000,%ecx
// ..............
10012e: e8 5d ff ff ff call 0x100090
100133: 89 1c 24 mov %ebx,(%esp)
100136: ba 40 00 00 00 mov $0x40,%edx
10013b: b8 40 10 10 00 mov $0x101040,%eax
100140: 89 54 24 08 mov %edx,0x8(%esp)
100144: 89 44 24 04 mov %eax,0x4(%esp)
100148: e8 43 ff ff ff call 0x100090

100121: 68 40 81 04 08 push $0x8048140
100126: ff 75 fc pushl -0x4(%ebp)
100129: e8 65 ff ff ff call 100093 <memcpy>
// ..............
100133: 68 80 81 04 08 push $0x8048180
100138: 8b 45 fc mov -0x4(%ebp),%eax
10013b: 05 a0 00 00 00 add $0xa0,%eax
100140: 50 push %eax
100141: e8 4d ff ff ff call 100093 <memcpy>

That's the generated code from MinGW (first example) and my cross-compiler (second example). You see that the addresses of the two strings are different. It's a problem with the cross-compiler/linker... I'm pretty sure of it, but I don't know how to fix it.

[Grunt]

I found the problem. Finally.

Adding -c to the compiler flags fixes it. (In case someone else will have the same problem)

[gravaera]

Hi:

I don't mean to bash, but:

This forum holds to a certain prerequisite base of knowledge before you ask questions. The wiki states that you are assumed to both know and understand thoroughly your development toolchain. Before you begin developing an OS, a certain level of 'programmer wisdom' should have been attained to. If you don't understand the basics of compiling relocatable object files for linkage, do you really think you can take proper advantage of your compiler, linker, or any other tool in your arsenal?

Please revise your stance and make a firm resolve to do better...

-All the best
gravaera

[Solar]

Adding -c to the compiler flags fixes it.

Pray tell, how many hoops did you have to jump through to make your stuff compile without error message regardless whether you give a -c or not?

I tried, but couldn't do it.

Oh, and your post is missing a central element:

Sorry for wasting everybody's time, I've been stupid.

The rule #1 of debugging (given to you for free because it's Tuesday).

1) Make a copy of your source tree.

2) Cut away everything not directly related to your problem.

3) Cut away everything you could cut away and still reproduce the problem.

4) Make sure there is positively nothing you could yet cut away while still reproducing the problem.

5) Post everything left over, explaining (in clear words) what result you expected and what you got instead (copy & paste error messages!).

5a) If you feel that would be too much to post on a forum, repeat 2) through 4).

The people you are asking for help should be able to compile the code you posted using the tools and command line options you posted and reproduce the problem on their machines.

Usually the problem resolves itself automatically somewhere between 2) and 5). If not, people can toy with your source and command lines themselves instead of playing "20 questions" with you.

This is not condescending flaming, this is the rule #1 of debugging.