LD.EXE under Windows Vista

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Kieran
Member
Member
Posts: 54
Joined: Mon Apr 11, 2005 11:00 pm

LD.EXE under Windows Vista

Post by Kieran »

I am currently having problems linking my kernel. The error I recieve is 'Cannot Read Symbols: Memory Exhausted' I have tried all sorts of memory options in LD.EXE, I have tried using the MingW LD, the DJGPP LD and the CygWin LD, none of them seem to work under Windows Vista.

Has anyone got LD working under Windows Vista?

If so, what formats are you using and what parameters do you pass to LD?

If anyone has any ideas of how to help, please let me know...

Thanks in advance,
Kieran Foot
White-spirit
Member
Member
Posts: 89
Joined: Sun Mar 23, 2008 2:23 pm
Location: [0x8:0x1000]

Post by White-spirit »

ld -V ?
Working on multi-tasking support ...
Kieran
Member
Member
Posts: 54
Joined: Mon Apr 11, 2005 11:00 pm

Post by Kieran »

My LD version info is:

GNU ld version 2.17.50 20060824
Supported Emulations:
i386pe
User avatar
-m32
Member
Member
Posts: 120
Joined: Thu Feb 21, 2008 5:59 am
Location: Ottawa, Canada

Post by -m32 »

I'm using Vista Ultimate x64, Cygwin's ld works fine for me:

From my makefile:

Code: Select all

@$(LD) -T$(LDSCRIPT) -o $(BIN)/kernel $(OBJS) $(LIBGCC)
How much RAM does your system have? What does your linker script look like?

I doubt very highly that Vista is the cause.
Kieran
Member
Member
Posts: 54
Joined: Mon Apr 11, 2005 11:00 pm

Post by Kieran »

I Run:

LD -T KRNL.LD -omgos.x

Here is my linker script:

Code: Select all

INPUT("ASTART.O")
INPUT("CMAIN.O")
INPUT("CMDPMT.O")
INPUT("CPUABIL.O")
INPUT("CPUID.O")
INPUT("FDD.O")
INPUT("GDT.O")
INPUT("HDD.O")
INPUT("IDT.O")
INPUT("IRQ.O")
INPUT("ISRS.O")
INPUT("KBD.O")
INPUT("KPRINTF.O")
INPUT("MM.O")
INPUT("PAGING.O")
INPUT("SCHED.O")
INPUT("SHUTDOWN.O")
INPUT("TIMER.O")
INPUT("VGA.O")
INPUT("VIDEO.O")
INPUT("../lib/libc.a")
OUTPUT_FORMAT("elf32-i386") 
ENTRY(_entry)
phys = 0x100000;
SECTIONS
{
  .text phys : AT(phys) {
    code = .;
    *(.text)
    *(.rodata)
    . = ALIGN(4096);
  }
  .data : AT(phys + (data - code))
  {
    data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss : AT(phys + (bss - code))
  {
    bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .;
}
User avatar
Zenith
Member
Member
Posts: 224
Joined: Tue Apr 10, 2007 4:42 pm

Post by Zenith »

Are you using the Cygwin LD, or a cross-compiled elf LD? If you're using the standard Cygwin one, stop right there and cross-compile binutils using the sources at gnu.org. I'm using Vista 32-bit, so I know that LD works under Vista.
"Sufficiently advanced stupidity is indistinguishable from malice."
hippykin
Posts: 11
Joined: Mon Feb 11, 2008 3:44 pm
Location: UK

Post by hippykin »

i am running LD (cygwin) on windows vista, i had to build a cross compiler because the version with cygwin has no support for elf files, i had terrible trouble with LD - it used to create ten meg executable for my kernel - which is nowhere near that size - eventually i had to use the MEMORY directive - this is my linker script:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
MEMORY 
  {
  ram (!rx) : ORIGIN = 0x100000, LENGTH = 256K
  }

SECTIONS
{
  .text : {  
    *(.text)
  } > ram
  
  .data  : {
    *(.data)
  } > ram
  
   .rodata : {
    *(.rodata)
    *(.rodata.1)
    *(.rodata.str1.4)
    *(.rodata.str1.1)
  } > ram
  
  .bss : {
    *(.bss)
  } > ram
} 
if you need to build a cross compiler for cygwin i can post the script file i made to build mine
The BBC micro could have become the world standard - it was so ahead of its time
User avatar
karloathian
Posts: 22
Joined: Fri Mar 28, 2008 12:09 am

Post by karloathian »

You're gonna have to build a cygwin cross-compiler to compile under windows vista. Windows Vista now restricts to 32 MB the memory of any DOS application , so that means that the only GNU compilers that work properly under vista are MinGW and Cygwin which internally use Windows calls instead of the standard library.

I've heard of people using DOSbox to use the GNU compiler, but I can really guarantee the performance.
Kieran
Member
Member
Posts: 54
Joined: Mon Apr 11, 2005 11:00 pm

Post by Kieran »

Ok, I am using i686 version of binutils and gcc.

I have managed to get rid of all previous errors.

I have had a mix of errors until now.

LD: PE operations on non PE file.
LD: Cannot read symbols: Memory exhausted

Now, I get a totally different error.

24 [main] LD 240 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1181 [main] LD 240 open_stackdumpfile: Dumping stack trace to ld.exe.stackdump
230784 [main] LD 240 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
232524 [main] LD 240 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)

I have now idea how I have caused this error. I'm just hopeing somebody can help...
User avatar
01000101
Member
Member
Posts: 1599
Joined: Fri Jun 22, 2007 12:47 pm
Contact:

Post by 01000101 »

doesn't vista only allow non-windows apps only 32MB of space? could you be going over that limit?
User avatar
B.E
Member
Member
Posts: 275
Joined: Sat Oct 21, 2006 5:29 pm
Location: Brisbane Australia
Contact:

Post by B.E »

Kieran wrote:Ok, I am using i686 version of binutils and gcc.

I have managed to get rid of all previous errors.

I have had a mix of errors until now.

LD: PE operations on non PE file.
LD: Cannot read symbols: Memory exhausted

Now, I get a totally different error.

24 [main] LD 240 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1181 [main] LD 240 open_stackdumpfile: Dumping stack trace to ld.exe.stackdump
230784 [main] LD 240 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
232524 [main] LD 240 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)

I have now idea how I have caused this error. I'm just hopeing somebody can help...
It may symptom of another problem. Is it possible for you to attach your OS code (or even just your compiled object files). Also have you compiled the thing from scratch lately.
Image
Microsoft: "let everyone run after us. We'll just INNOV~1"
Post Reply