Page 2 of 4

Re: please help AHHHH ld and gcc problem ?

Posted: Tue Jan 13, 2009 4:02 pm
by Sam111
I will try it tonight when I get home from work.

But it's not a question of me not understanding it. It's a question of why it's not working.

Basically you begin in your main c file.

main is your entry point.
then main calls asmFunc(); which is declared external so that at linking time it resolves the asmFunc in myAsm.asm. Which then calls back to the myFunc() (which needed to be declared external in the asm file and at link time it resolve it's symbol. ) . At that point the myFunc() calls puts which prints hello.

Yes you are right it is probably easier to get this to go first with entry point in c.
But my main objective is to have the entry point in the asm file so I can just call to the c function but begin in the asm file.

Thanks for all your help so far.

Re: please help AHHHH ld and gcc problem ?

Posted: Tue Jan 13, 2009 6:11 pm
by Sam111
Ok , I try it.

I took this

Code: Select all

BITS 32
segment code
global _callASM
_callASM:
extern _backToC
call _backToC
label2:
jmp label2
and my c code

Code: Select all



#include <stdio.h>

extern void callASM() ; 
 
void write_string(int colour, const char *string)
{
	volatile char *video=(volatile char*)0xB8000;
	while(*string!=0)
	{
		*video=*string;
		string++;
		video++;
		*video=colour;
		video++;
	}
	return ;
}

void printit(int i , const char * string )
{
printf( string ) ;
return ;
}

void backToC()
{
puts( "hello I am working!" ) ;
return ;
}


int main()
{

callASM() ;

}
Note the only function I am using in c is backToC and the main function the others are left in for latter use .

Here what happened.
I compile asm file like you said using coff . Compiles fine!
Then I gcc -c video.c which compiles fine as would expect.
Then I do gcc video.o callfunc.o this gives me an a.exe.

But when I run it I get this

Code: Select all


Exiting due to signal SIGSEGV
General Protection Fault at eip=0002002f
eax=00000000 ebx=00000297 ecx=ffffffff edx=0000033e esi=00000054 edi=0000fb60
ebp=0013ffe1 esp=0013ffba program=C:\ASM_PR~1\A.EXE
cs: sel=01a7  base=02970000  limit=0013ffff
ds: sel=01af  base=02970000  limit=0013ffff
es: sel=01af  base=02970000  limit=0013ffff
fs: sel=017f  base=00005f10  limit=0000ffff
gs: sel=01bf  base=00000000  limit=0010ffff
ss: sel=01af  base=02970000  limit=0013ffff
App stack: [00140000..000c0000]  Exceptn stack: [0000fac0..0000db80]

Call frame traceback EIPs:
  0x0002002f
  0x0100002e
So It is a General Protection Fault at eip=0002002f.
I am testing on a windows xp intel pentium 4 processor.

I tried this below , could it be because I should have called the (segment/section) text and not code.
Maybe you cann't access section code from text ?

Code: Select all


C:\ASM_PR~1>objdump -h a.exe

a.exe:     file format coff-go32-exe

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000a508  000010f8  000010f8  000018f8  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00001200  0000b600  0000b600  0000be00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00003400  0000c800  0000c800  00000000  2**2
                  ALLOC
  3 code          00000008  0000fc00  0000fc00  0000d400  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  4 .comment      00000010  0000fc08  0000fc08  0000d408  2**2
                  CONTENTS, DEBUGGING

Re: please help AHHHH ld and gcc problem ?

Posted: Tue Jan 13, 2009 6:47 pm
by Sam111
Yup,
segment code in the asm doesn't work. you need to change it to segment .text.

Then it works fine. YEEEEEEEESSSSSSSSSSSSS

This is objdump stuff after it is working

Code: Select all

C:\ASM_PR~1>objdump -h a.exe

a.exe:     file format coff-go32-exe

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000a530  000010d0  000010d0  000008d0  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00001200  0000b600  0000b600  0000ae00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00003400  0000c800  0000c800  00000000  2**2
                  ALLOC
  3 .comment      00000010  0000fc00  0000fc00  0000c000  2**2
                  CONTENTS, DEBUGGING



I guess PE executable files have to have the exact segment/section headers as the asm file.
Wonder If it is possible to have a user defined segment inside the PE and somehow jump to it.

Like if I had created segment userseg in my asm. When I link it to my c main file and get an output exe.
I see that it does create the segment/section in the PE of userseg but if you try accessing I think bad things will happen. This is why I was getting the fault. I am just curious if you can make a user defined section accessable from the main .text segment of the PE. Their must be something like granting it security permissions or making the segment global.

God I love objdump.

Anyway I will try moving the main entry point to asm.
I will let you know when I get the chance if I have any problems. But I can stress it enough.

Thank You

Re: please help AHHHH ld and gcc problem ?

Posted: Wed Jan 14, 2009 1:26 am
by Solar
Sam111 wrote:God I love objdump.
If it's allowed for a non-Christian to say so - amen. ;-)

Re: please help AHHHH ld and gcc problem ?

Posted: Wed Jan 14, 2009 1:58 am
by ru2aqare
Sam111 wrote:Yup, segment code in the asm doesn't work. you need to change it to segment .text.
...
I guess PE executable files have to have the exact segment/section headers as the asm file.
Wonder If it is possible to have a user defined segment inside the PE and somehow jump to it.
Congrats on getting it work. However I still don't understand why custom sections would not work. It worked for me, though I created one from C, and it was a read-only data segment.

Re: please help AHHHH ld and gcc problem ?

Posted: Wed Jan 14, 2009 9:26 am
by Sam111
Congrats on getting it work. However I still don't understand why custom sections would not work. It worked for me, though I created one from C, and it was a read-only data segment.
I don't quite understand. How did you create in C a user defined section. Didn't know you can specify segments in C. I thought the C compiler/linker creates these things for you. Do you mean you used some gcc switch that allows you to create a user defined segment. Or do you mean you created a user defined segment in nasm and linking it to your main c files. Because the previous sentence you can do. But then you probably won't beable to access this segment from the .text section. But maybe data sections are different then code sections permission wise for PE. And the OS allows you to access them. I wonder??? [-o< (maybe you need the . before your user defined section header for the PE to reconignize it as a vaild section ? Duno maybe that's is what allowed you.
Anyway you where on a microsoft os when you where testing this right?

Also I got the entry point to be in the asm code but you need to use

Code: Select all

global _main
_main:
gcc / ld allows you to define the entry point to be whatever you want (i.e it could be myentry )
Also you could do it with a linker script. But whatever

However for PE I think the entry point must be _main. Correct me if I am wrong?

Also, I found in Visual Studio the equivalent of objdump it is called dumpbin. And it allows you to analysis's PE exe files. objdump only analysis coff , elf , a.out, ..etc. but not PE that where linked with .obj files (RDOFF) so dumpbin closes the gap. This was a cool fined thought I would share.

Now I am going to try getting this whole thing working with microsoft visual studios cl , link.
The cl creates the .obj file format Relocatable Dynamic Object File Format (RDOFF ) then link will link into a PE .

I will let you guys know if I get it to go and what switches I used. The only thing I don't think cl/link can do is compile/link to bin file's. (And their is no such thing as linker scripts in microsoft world)
So even though you can use the visual studio's IDE. I don't think you can use cl/link to write a kernel.
You need gcc/ld to create the bin file. However I could be wrong.

I am also wondering if gcc/ld supports RDOFF I know nasm assemblier does or at least has a tool in it's nasm folder for converting ?

:mrgreen:

Re: please help AHHHH ld and gcc problem ?

Posted: Wed Jan 14, 2009 10:25 am
by ru2aqare
Sam111 wrote: I don't quite understand. How did you create in C a user defined section. Didn't know you can specify segments in C. I thought the C compiler/linker creates these things for you. Do you mean you used some gcc switch that allows you to create a user defined segment. Or do you mean you created a user defined segment in nasm and linking it to your main c files. Because the previous sentence you can do. But then you probably won't beable to access this segment from the .text section. But maybe data sections are different then code sections permission wise for PE. And the OS allows you to access them. I wonder??? [-o<
I use msvc and masm, both of which allow custom segments. You are correct that this is not standard C. I use

Code: Select all

#pragma code_seg(push, "custom segment name here up to 7 chars")
for C, and for assembly I used

Code: Select all

_TEXT$1 segment public para 'CODE'
_TEXT$1 ends
_TEXT$2 segment public para 'CODE'
_TEXT$2 ends
; etc.
to get the correct segment ordering without linker scripts. My linker currently doesn't support linker scripts, but this is a workaround for the time being.
Sam111 wrote:However for PE I think the entry point must be _main. Correct me if I am wrong?
No, not correct. The entry point can be whatever you choose. Most linkers do default to main/_main/_WinCRTStartup/NtProcessStartup/whatever, but all linkers have an option to set the entry point to an arbitrary symbol.
Sam111 wrote: Also, I found in Visual Studio the equivalent of objdump it is called dumpbin. And it allows you to analysis's PE exe files. objdump only analysis coff , elf , a.out, ..etc. but not PE that where linked with .obj files (RDOFF) so dumpbin closes the gap. This was a cool fined thought I would share.
Nice find, although I already knew about it.
Sam111 wrote: Now I am going to try getting this whole thing working with microsoft visual studios cl , link.
The cl creates the .obj file format Relocatable Dynamic Object File Format (RDOFF ) then link will link into a PE .
I think it still creates plain COFF files. When you enable the Link-Time Code Generation option, you get a hacked COFF file format that contains some CIL-resembling code. I haven't been able to get my linker understand it, so I always disable this option.
Sam111 wrote: I will let you guys know if I get it to go and what switches I used. The only thing I don't think cl/link can do is compile/link to bin file's. (And their is no such thing as linker scripts in microsoft world)
So even though you can use the visual studio's IDE. I don't think you can use cl/link to write a kernel.
You need gcc/ld to create the bin file. However I could be wrong.
No, it can't do plain binary files, the MS linker always outputs a PE file. However that doesn't keep you from copying part of the PE file to a binary file. I used this approach until like half a year ago, when I get fed up with this and wrote instead my linker. Which can output plain binary files, and won't stop you from mixing object files that contain 16, 32 and 64-bit code.
And you can definitely use msvc to write a kernel. I am using it to compile my boot loader and kernel, so it can be done.

Re: please help AHHHH ld and gcc problem ?

Posted: Wed Jan 14, 2009 12:39 pm
by Sam111
And you can definitely use msvc to write a kernel. I am using it to compile my boot loader and kernel, so it can be done.
How then if you cann't compile to a bin with cl/link ?
I mean I guess if your are somehow converting the obj to bin or using dumpbin and extracting the needed sections.

And how in visual studio's do you compile an asm file? I only ever compiled c , c++ , j# , C# , or vb.
Do I have to enable something in the properties of the project. And I would think masm syntax is a little different then nasm , yasm , or tasm (which I have worked with alot). Anyway It would be great if somebody could show my how to assembly/compile/link an asm file in VS ?

I have written inline asm in C but never wrote a asm file and compiled it to obj in VS then linked it with the asm entry point??? (I don't even know how to compile asm thru VS?)

And I would believe you would have to use masm asm syntax in my asm files thus I would have to modify all my asm files for that. Which does suck but I do want to know how to do asm thru VS.
I am using VS2005 on my windows xp machine with .net version SP 2. [-o<

ya and obviously you can create your own linker but I wanted to know if you can do it with VS without having to use any 3 party stuff. (that is create a kernel which need to be in bin format)
Maybe you can compile all your files to obj but then you would have to use some linker that supports linking to a bin file. In nasm you cann't use extern's keyword for bin so you have to use a different format, compile, linker or whatever. I only ever say it done in elf or aout format a kernel.

Re: please help AHHHH ld and gcc problem ?

Posted: Wed Jan 14, 2009 6:54 pm
by Sam111
O I think I figured out how you can do asm thru VS2005 by using masm.

Do ml /coff /c yourbootloader.asm (/c means only compile)

But this will produce a coff object file.

I have read that if you add to an empty c project an .asm file then it will assembly it with masm and recognize it in VS2005 for you when you hit the compile button.

I am just worried about what the difference is between coff .o and .obj which cl produces and if link will beable to link them for you. If they can be linked together or if their is a switch to tell cl to produce coff then I think I would be all set because then I could do link /entry myentrypoint /NODEFAULTLIB ...etc etc

Then I think you could use dumpbin to get the sections into a bin file.

Anyway what the heck is the difference between OMF ,RDOFF and coff . And if I mix them when linking will
it be ok? I think OMF is just an extension of coff and I am wondering if the linker will link the 2 together properly?

I Know but correct me if I am wrong VS2005 allows you to create lib , dll , exe. But their is no way to tell the VS2005 to compile into a bin it only compiles to the above 3. So in order to get it to bin you first have to take the PE and create a bin out of it using another tool.

I am wondering if VS2005 can output com files , I would think not because the only difference between com and bin is org 100h. And this would be easy to convert to a bin.

In linux we don't have these problems because ld supports bin , and gcc supports elf , aout, coff each of these can have external references in them.

Other then writing your own linker or using third party software is it possible to get a bin out of VS2005 compiler/linker/assembliers .

Re: please help AHHHH ld and gcc problem ?

Posted: Thu Jan 15, 2009 3:04 am
by ru2aqare
Sam111 wrote:O I think I figured out how you can do asm thru VS2005 by using masm.

Do ml /coff /c yourbootloader.asm (/c means only compile)
I actually created a custom rule file for assembly outputs, that runs a small utility I wrote, and decides which masm version to run (x86 or x64) based on the file name. So when I set the target to x64, it runs the x64 version of masm, and vice versa.
Sam111 wrote: I am just worried about what the difference is between coff .o and .obj which cl produces and if link will beable to link them for you. If they can be linked together or if their is a switch to tell cl to produce coff then I think I would be all set because then I could do link /entry myentrypoint /NODEFAULTLIB ...etc etc
There is no difference between the .obj files generated by cl or masm and the .o files generated by gcc on Cygwin. Both use the COFF format, and can actually be linked together (I haven't tried this yet, but theoretically it is possible).
Sam111 wrote: Anyway what the heck is the difference between OMF ,RDOFF and coff . And if I mix them when linking will
it be ok? I think OMF is just an extension of coff and I am wondering if the linker will link the 2 together properly?
OMF: Object Module Format. Used by (older) Borland tools, and anything that produces output for DOS. I think even Borland abandoned this format by now in favor of COFF. This is a rather complex file format, and that's probably why nothing supports it nowadays.
RDOFF: haven't encountered this one yet.
COFF: the Common Object File Format (I think this is its name) we all love. It's pretty simple compared to other object file formats.
Sam111 wrote: I Know but correct me if I am wrong VS2005 allows you to create lib , dll , exe. But their is no way to tell the VS2005 to compile into a bin it only compiles to the above 3. So in order to get it to bin you first have to take the PE and create a bin out of it using another tool.
That's right, and that's why I created a custom linker that can replace the one that comes with VS and allows you to create flat binary files. Do you want to test it? It may solve your problem of generating flat binary files...
Sam111 wrote: I am wondering if VS2005 can output com files , I would think not because the only difference between com and bin is org 100h. And this would be easy to convert to a bin.
I don't think it can. The linker may have an option for it though... (check the documentation or MSDN).
Sam111 wrote: In linux we don't have these problems because ld supports bin , and gcc supports elf , aout, coff each of these can have external references in them.

Other then writing your own linker or using third party software is it possible to get a bin out of VS2005 compiler/linker/assembliers .
See previous answer.

Re: please help AHHHH ld and gcc problem ?

Posted: Thu Jan 15, 2009 11:44 am
by Sam111
Then I am curious why when I create a PE with cl /link and try to use objdump it say's something like format not supported. However when I create a PE with gcc/ld then the objdump works fine and it gives the format as coff2go...etc. Simalary things happen the other way around i.e when I do dumpbin for PE created by gcc/ld doesn't work but with objdump does work?

If they where really both the same format then won't both tools objdump and dumpbin recognize the format. (COFF) That is why I am saying they must be different formats.

But it is a bummer that we cann't do bin's with VS. At best we can just compile to obj and use another linker that supports these and can link to bin.
Curious to know if .obj can be linked with gcc/ld to a bin?

Anyway can I see your linker or can you explain how you wrote it!
How Do You Do It Manual??????????????????????????????????
Could you just copy the data and text segments out of the PE or do you have to fix some address's
after you copied the segment?

I guess what I am ask is how do you write a linker for coff. How does the linker merge .data, .text ,...etc all into one .data or .text ..etc segment. Without have to change the address of calls and jmps in each of the text sections. Seems hard?

Re: please help AHHHH ld and gcc problem ?

Posted: Thu Jan 15, 2009 1:11 pm
by ru2aqare
Sam111 wrote:Then I am curious why when I create a PE with cl /link and try to use objdump it say's something like format not supported. However when I create a PE with gcc/ld then the objdump works fine and it gives the format as coff2go...etc. Simalary things happen the other way around i.e when I do dumpbin for PE created by gcc/ld doesn't work but with objdump does work?
If they where really both the same format then won't both tools objdump and dumpbin recognize the format. (COFF) That is why I am saying they must be different formats.
I have no idea. Are you sure you turned off Link-Time Code Generation in the cl compiler options?
Sam111 wrote: Anyway can I see your linker or can you explain how you wrote it!
Here it is: clicky. Readme included, ask me or PM if you have questions. You can add a post-build (or pre-link) event and invoke the linker, and it will generate the output. The VS linker may fail, but you will have your output file anyway. This is the setup I have been using, although I admit it would be a much nicer solution to replace the VS linker altogether, but I haven't found a way to do that.
Sam111 wrote:I guess what I am ask is how do you write a linker for coff. How does the linker merge .data, .text ,...etc all into one .data or .text ..etc segment. Without have to change the address of calls and jmps in each of the text sections. Seems hard?
It is not that hard. Basically you just merge all code sections, data sections, etc. and resolve the addresses.

Re: please help AHHHH ld and gcc problem ?

Posted: Thu Jan 15, 2009 2:17 pm
by Sam111
Thanks for the link. Great Job. =D>
Anyway I was wondering if you can explain to me how you actually convert a PE to a bin or take obj's and link them into bin. I just want a general algorithm i.e first check symbol table ....etc

I would think their is alot to do with changing address's in jmp or call statements.

Say you have object1.obj and object2.obj they both have .data .text sections

When you compiled object1.c to get object1.obj what is the hex value they use for a statement in object1.obj .text
like
mov eax , an_external_symbol_that_is in_object2 ?

I know they have some entry in the symbol table so that the linker can resolve the symbol. But what do they put in it's place in the .text section before it is resolved. Their must be something that delimits it from an instruction like mov eax , 33d or something. I mean the compiler does have to compile mov eax , an_external_symbol_that_is in_object2 down into something even though it cann't find it's symbol or address until linking?

If I have a PE I know I can just use the entry point address in the PE and create a jmp statement to that address after I extracted the .data , .text sections using objdump.

But if I have seperate obj files how does the linker merge the sections .data ...etc all into one data ...etc without screwing up addresses that the .text section's refer to ???

Re: please help AHHHH ld and gcc problem ?

Posted: Thu Jan 15, 2009 4:57 pm
by ru2aqare
Sam111 wrote:Say you have object1.obj and object2.obj they both have .data .text sections
When you compiled object1.c to get object1.obj what is the hex value they use for a statement in object1.obj .text
like
mov eax , an_external_symbol_that_is in_object2 ?


I calculate the layout of each section (with respect to section alignment), then calculate the updated addresses of all symbols, finally all references to symbols are updated. That's it.
Sam111 wrote: I know they have some entry in the symbol table so that the linker can resolve the symbol. But what do they put in it's place in the .text section before it is resolved. Their must be something that delimits it from an instruction like mov eax , 33d or something. I mean the compiler does have to compile mov eax , an_external_symbol_that_is in_object2 down into something even though it cann't find it's symbol or address until linking?
Compilers usually put zeros in such locations. That's why you can't usually run an executable that has link-time errors (unresolved references, etc). It will just crash.

Re: please help AHHHH ld and gcc problem ?

Posted: Thu Jan 15, 2009 10:29 pm
by Sam111
I calculate the layout of each section (with respect to section alignment), then calculate the updated addresses of all symbols, finally all references to symbols are updated. That's it.
Assuming I have a PE and search it to find that .data , .text begain at

Code: Select all

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00008730  000010d0  000010d0  000008d0  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00000e00  00009800  00009800  00009000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00003400  0000a600  0000a600  00000000  2**2
                  ALLOC
  3 .comment      00000010  0000da00  0000da00  00009e00  2**2
                  CONTENTS, DEBUGGING
So .text begins at 000010d0 .

If I objdump the .text and data sections to a file.

Code: Select all

hello.exe:     file format coff-go32-exe

Contents of section .text:
 10d0 1e07f605 7db90000 017525b8 d0100000  ....}....u%.....
 10e0 3d001000 007c1966 b8070564 8b351800  =....|.f...d.5..
 10f0 000031db b9010000 00ba7698 0000cd31  ..1.......v....1
 1100 668cdb66 b80a00cd 317304b4 4ccd2166  f..f....1s..L.!f
 1110 a3e43000 0089c366 b8090066 8cc983e1  ..0....f...f....
 1120 03c1e105 6681c993 c0cd3166 b9ffff89  ....f.....1f....
 1130 ca66b808 00cd310f 03db4374 1080257c  .f....1...Ct..%|
 1140 b900007f 800d7db9 000080eb 1bf6057c  ......}........|
 1150 b9000080 7412668c cb66b808 00cd3166  ....t.f..f....1f
 1160 8cdb66b8 0800cd31 f6057db9 00000874  ..f....1..}....t
 1170 7abe0498 00000fb7 5e08c1eb 0466b800  z.......^....f..
 1180 01cd3173 04b44ccd 21668c4e 02668c5e  ..1s..L.!f.N.f.^
 1190 04668956 060fb706 a3709800 00068ec2  .f.V.....p......
 11a0 b96c0000 00c1e902 31fffcf3 a50789d3  .l......1.......
 11b0 66b80b00 bf00a600 00cd3180 2506a600  f.........1.%...
 11c0 00bf8025 05a60000 f0800d05 a600000a  ...%............
 11d0 31c066b9 0100cd31 66a37498 000089c3  1.f....1f.t.....
 11e0 66b80c00 bf00a600 00cd31bf 64b10000  f.........1.d...
 11f0 893d0098 000031c0 39077407 890783c7  .=....1.9.t.....
 1200 04ebf566 8ccb66b8 0600cd31 891558b1  ...f..f....1..X.
 1210 00006689 0d5ab100 0064a11c 000000a3  ..f..Z...d......
 1220 0ca60000 a354ad00 0089cb89 d16681c1  .....T.......f..
 1230 001083d3 002d0010 000050e8 4d010000  .....-....P.M...
 1240 64a11800 0000a35c b1000064 a1100000  d......\...d....
 1250 0050e859 01000083 f8ff746c a360b900  .P.Y......tl.`..
 1260 0089c764 8b0d1000 0000c1e9 0231f61e  ...d.........1..
 1270 0fa01ffc f3a51fa1 54b10000 648b0d14  ........T...d...
 1280 00000039 c87d0789 c8a354b1 000050e8  ...9.}....T...P.
 1290 1c010000 83f8ff74 2fa350ad 00000305  .......t/.P.....
 12a0 54b10000 668cda8e d224f889 c431ed68  T...f....$...1.h
 12b0 7a980000 6870a100 00e8c205 000083c4  z...hp..........
 12c0 08e8f21a 0000eb0c b0ffeb08 8d742600  .............t&.
 12d0 8a442404 88c131c0 8ee08ee8 fa668b1d  .D$...1......f..
 12e0 dad80000 66b80100 cd31668b 1de43000  ....f....1f...0.
 12f0 0066b801 00cd31f6 057db900 0008741a  .f....1..}....t.
 1300 668b1d74 98000066 b80100cd 31668b15  f..t...f....1f..
 1310 0a980000 66b80101 cd318b15 60b90000  ....f....1..`...
 1320 8b422866 a3749800 0031ff89 3d709800  .B(f.t...1..=p..

...on an on
 97e0 00000000 00000000 00000000 00000000  ................
 97f0 00000000 00000000 00000000 00000000  ................
Contents of section .data:
 9800 64b10000 12000000 00000000 70020000  d...........p...
 9810 00000000 00008cd8 2e8e1e06 00a31000  ................
 9820 8c160a00 6689260c 008e1606 0066bc70  ....f.&......f.p
 9830 020000b8 0305cd31 722489ca 89d98b1e  .......1r$......
 9840 0200b807 00cd318b 1e0400b8 0700cd31  ......1........1
 9850 06070fa0 0fa10fa8 0fa989cb 89d18e16  ................
 9860 0a00668b 260c008e 1e100066 cb909090  ..f.&......f....
 9870 00000000 00000000 00000000 00000000  ................
 9880 00000000 00000000 00000000 00000000  ................
 9890 00000000 00000000 00000000 00000000  ................
 98a0 00000000 00000000 0000b801 00cd31b8  ..............1.
 98b0 0205cd31 88d0b44c cd2164b9 00000099  ...1...L.!d.....
 98c0 0000e015 00000cd9 00000000 00000000  ................
 98d0 47726565 74696e67 7320616e 64207765  Greetings and we
 98e0 6c636f6d 65200d0a 24000000 00000000  lcome ..$.......
 98f0 00000000 00000000 00000000 00000000  ................
 9900 2449643a 20444a47 5050206c 69626320  $Id: DJGPP libc 
 9910 6275696c 74204465 63203234 20323030  built Dec 24 200
 9920 31203231 3a32343a 33392062 79206763  1 21:24:39 by gc
on and on.... to the end of file
Question
If I load this file into memory 000010d0 and jmp to 000010d0 would it be the exact program with no problems in running it.

Also If I want to load it to some other memory address say 00003456. I would first have to find the entry point symbol in the symbol table then find it's memory size then update it with 00003456. And then we would have the next symbol at 00003456 + size of starting entry = next need to be updated symbol.

I think the best way to go about this is to sort the symbols starting with the entry point first followed by the next closes address symbol ...etc then calculate the length between each symbol in the array.
Then 00003456 + size entry = second symbol , and second symbol + size of second symbol = third ...so on

Then I would think all you would have to do is go thru the .text segment and update any references to symbols with the new symbol value in the symbol table.

But here is my problem how do you know from traversing the .text section what is referencing a symbol after you updated the symbol table. It is all hex it could be you have call 0x0403 that is meant to call that direct address or you could have a symbol that = 0x0403. How do you delimit symbols in a .text section from actual fixed address. Even so I would think even the fix address would have to be update with 00003456 +- .

But maybe I am not understanding something about the symbol table. Looks to me it is just symbols and starting address's of symbols. If I change some address in the symbol table with the update version how when I traverse the .text will I know if it was a symbol (you would still need the old symbol values to know what locations to change.......confusion on changing numbers in .text section from updated symbol table.

Code: Select all

Something like 
    114b:	eb 1b                	jmp    1168 <ds_alias_ok+0x59>
How does it know to update eb 1b = jmp <ds_alias_ok+0x59> with the new value of ds_alias_ok from just the eb 1b. jmp 1168 would have to be update but their is no symbol corosponding to it so how would you know to update this. You would first have to dissassembly to see this <ds_alias_ok+0x59>
then you could substitute the value for ds_alias_ok into <ds_alias_ok+0x59>

snippet of symbol table

Code: Select all

[729](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000036a0 gcc2_compiled.
[730](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000036a0 ___gnu_compiled_c
[731](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x000036a0 .text
AUX scnlen 0x20 nreloc 0 nlnno 0
[733](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x000099b0 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[735](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x0000a6c0 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[737](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x00000301 dpmiexcp.c
File 
[739](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000036c0 gcc2_compiled.
[740](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000036c0 ___gnu_compiled_c
[741](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x000099b0 _old_video_mode
[742](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x000099b4 _cbrk_vect
[743](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000a6c0 _buf.48
[744](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000036c0 _itox
[745](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x0000370c _except_to_sig
[746](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000037e4 _show_call_frame
[747](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x000099b8 _exception_names
[748](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00009a00 _has_error
[749](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000039cc _dump_selector
[750](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x00003b7c _do_faulting_finish_message
[751](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000a6d0 _signal_list
[752](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x00003fea _signames
[753](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x00004048 _print_signal_name
[754](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00009a12 _cbrk_hooked
[755](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000abd0 _except_ori
[756](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000ac68 _npx_ori
[757](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000ac60 _kbd_ori
[758](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000ac78 _cbrk_ori
[759](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000ac7c _cbrk_rmcb
[760](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000ac80 _cbrk_regs
[761](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x0000ac70 _timer_ori
[762](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x000043f8 _set_signal_key
[763](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x000036c0 .text
AUX scnlen 0xfc8 nreloc 265 nlnno 0
[765](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x000099b0 .data
AUX scnlen 0x64 nreloc 17 nlnno 0
[767](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x0000a6c0 .bss
AUX scnlen 0x5f4 nreloc 0 nlnno 0
[769](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x00000309 fake
File 
[771](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00004690 .text
AUX scnlen 0x74 nreloc 1 nlnno 0
[773](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00009a20 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[775](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x0000acb4 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[777](sec -2)(fl 0x00)(ty   0)(scl 103) (nx 1) 0x00000313 getenv.c
File 
Don't know what all this crap means below

Code: Select all

[731](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1)... important stuff like start address symbol name...