How large file can be processed by the linker "ld"?

2008-10-31 Thread shihhuangti
Today, I make the whole project at my office, and the obj generated with 
opition "-g3", and when final linking, I keep the dbg-info within the 
exe-file, but failed with the message "memory exhausted", and later I find 
there is a objfile passed to the linker ld and the file is of size 1.9G.

I want to know it is a bug or not? How large file (the upper limit) can be 
processed by the linker "ld"?___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


答复: Re: ´ð¸´: Re: How large fil e can be processed by the linker "ld"?

2008-11-17 Thread shihhuangti
Hi, Nick,

thanks for your suggestion, I'll try it tomorrow.

from your reply about my using option  "-X -s", I think it is necessary to 
detail the prcess of my operation:

Step first, I use option "-r" to link all the objs together(without option 
"-X -s"), and it succeed; the output obj file has size of 2G bytes above;

Step second, I use option  "-X -s" with option "-r", but ld failed.

it is diffcult to me to explain why this happens, for the memory required 
by the second step should be smaller the the first step(because the ld can 
drop some section within every obj file); and the first functions, why the 
second doesn't? additionly, the ld doesn't generated any message like 
"memory exhausted" which it does when I want to generate a exe-file (have 
hot reloc info), So I think the error happens during at second step may 
due to some other cause but not about the available memory amount.





Nick Clifton <[EMAIL PROTECTED]> 
2008-11-18 00:21

收件人
[EMAIL PROTECTED]
抄送
bug-binutils@gnu.org
主题
Re: ´ð¸´: Re: How large file can be processed by the linker "ld"?






Hi shihhuangti,

> I want to know why the linker use such amount memory to put the objs 
> together? it is possible to be optimized?

Yes, but it would be a lot of work.  (Essentially it would mean 
rewriting the linker with minimizing memory usage as the main aim).  But 
... this does suggest an alternative - have you tried using a different 
linker ?  There are two that I know of that might work for you - the 
"gold" linker which is currently under development in the binutils 
project and the linker which comes with the elfutils project.  (I am not 
really involved in the elfutils project so I cannot tell you any more 
about their linker).  The gold linker can be built from the current 
binutils sources by specifying --enable-gold on the configure command 
line.  Give it a try and see if it helps.

> if I doesn't use option  "-X -s" when invoking the linker ld, and with 
> option "-r" the relocated obj file can be generated which has size of 2g 

> bytes above.
> 
> I think this is a bug, am I right?

I don't think so.  The problem is that you are dealing with a very big 
program and you are attempting to link it on a machine with only a 
limited amount of memory.

Cheers
   Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


答复: Re: ´ð¸´: Re: How large fil e can be processed by the linker "ld"?

2008-11-26 Thread shihhuangti
Hi nick,

the gold doesn't help too;

after my reading the ld's code and debugging it, I find the reason of the 
latter problem: maybe it is due to the gcc's bug( about when using "-g3", 
some asm-inlined function may be placed in section ".debug_macinfo", but 
the maintainer doesn't think so), and I use another method of inlining asm 
code to avoid the latter problem;

the first problem about ld is the output of error message "memory 
exhausted", after reviewing of the src code, I think I can resolve it by 
modification of the code.





Nick Clifton <[EMAIL PROTECTED]> 
2008-11-18 00:21

收件人
[EMAIL PROTECTED]
抄送
bug-binutils@gnu.org
主题
Re: ´ð¸´: Re: How large file can be processed by the linker "ld"?






Hi shihhuangti,

> I want to know why the linker use such amount memory to put the objs 
> together? it is possible to be optimized?

Yes, but it would be a lot of work.  (Essentially it would mean 
rewriting the linker with minimizing memory usage as the main aim).  But 
... this does suggest an alternative - have you tried using a different 
linker ?  There are two that I know of that might work for you - the 
"gold" linker which is currently under development in the binutils 
project and the linker which comes with the elfutils project.  (I am not 
really involved in the elfutils project so I cannot tell you any more 
about their linker).  The gold linker can be built from the current 
binutils sources by specifying --enable-gold on the configure command 
line.  Give it a try and see if it helps.

> if I doesn't use option  "-X -s" when invoking the linker ld, and with 
> option "-r" the relocated obj file can be generated which has size of 2g 

> bytes above.
> 
> I think this is a bug, am I right?

I don't think so.  The problem is that you are dealing with a very big 
program and you are attempting to link it on a machine with only a 
limited amount of memory.

Cheers
   Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/7073] New: when the obj file's length exceed the limitation, the linker exit with errors

2008-12-05 Thread shihhuangti at 163 dot com
when using the gnu linker ld, I find the error occures when there is one of the
objs which to be handled by linker and which has a huge elf section(such as the
sec .debug_macinfo when using option -g3) .

code segment locate at file elflink.c
...
  /* Allocate some memory to hold information read in from the input
 files.  */
  if (max_contents_size != 0)
{
  finfo.contents = bfd_malloc (max_contents_size);
  if (finfo.contents == NULL)
goto error_return;
}
...

during my modification of the code , I resolved the problem, and I wish to give
some clue to the ld's maintainer to improve the ld:

I use the disk file to store the max sec's content instead of keep them in
memory, when we want to modification the sec's content I will write the
modification back to the file; when we want to get some info from the section, I
will open the file and fseek, then fread; 

all of the above are realized by tracing the usage of "finfo.contents", I use a
totally equivalence way to assure the correctness.

of course, the ld needs much more time to finish the work: I use the ld after
doing my modification to link some obj file together, and to generate one huge
execuable elf file whose length almost exceed the 2G bytes, and it takes almost
one hour.

if the info above does help to the new version's development, i will post some
code segment.

-- 
   Summary: when the obj file's length exceed the limitation, the
linker exit with errors
   Product: binutils
   Version: 2.19
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: shihhuangti at 163 dot com
CC: bug-binutils at gnu dot org,nickc at redhat dot com
  GCC host triplet: cygwin for powerpc target
GCC target triplet: all target


http://sourceware.org/bugzilla/show_bug.cgi?id=7073

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils