public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Regarding linker code generation
       [not found] <1185763943.19324.ezmlm@sourceware.org>
@ 2007-07-30 14:24 ` Bhushan Verma
  2007-08-01 17:38   ` Nick Clifton
  0 siblings, 1 reply; 8+ messages in thread
From: Bhushan Verma @ 2007-07-30 14:24 UTC (permalink / raw)
  To: binutils

Dear ALL,

Could you please help me to sort out my problem.

Actually whenever I run my  run time linker on unix like OS (arm) with
following Program header
This run well.

Program Header[0]:
    p_vaddr:      0           p_flags:    [ PF_X PF_W PF_R ]
    p_paddr:      0           p_type:     [ PT_LOAD ]
    p_filesz:     0x2bc1f     p_memsz:    0x2d6c8
    p_offset:     0           p_align:    0x8000

Why linker is generating this type of header?

But whenwver I separate code and data segment this gives segmentation fault
inside self relocation of run time linker.
after separation of code and data segment of run timer linker:

Program Header[0]:
    p_vaddr:      0           p_flags:    [ PF_X PF_R ]
    p_paddr:      0           p_type:     [ PT_LOAD ]
    p_filesz:     0x2b094     p_memsz:    0x2b094
    p_offset:     0           p_align:    0x8000

Program Header[1]:
    p_vaddr:      0x330a4     p_flags:    [ PF_W PF_R ]
    p_paddr:      0x330a4     p_type:     [ PT_LOAD ]
    p_filesz:     0xa2b       p_memsz:    0x24d4
    p_offset:     0x2b0a4     p_align:    0x8000

I am using gnu arm toolchain
Could you please help me is this due to permiison of data segment or I have
some other problem as in creating wrong data segment etc.
could you please explian me p_vaddr Vs p_paddr.

Regards
Verma





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Regarding linker code generation
  2007-07-30 14:24 ` Regarding linker code generation Bhushan Verma
@ 2007-08-01 17:38   ` Nick Clifton
  2007-08-02  1:21     ` Bhushan Verma
  0 siblings, 1 reply; 8+ messages in thread
From: Nick Clifton @ 2007-08-01 17:38 UTC (permalink / raw)
  To: Bhushan Verma; +Cc: binutils

Hi Verma,

> Program Header[0]:
>     p_vaddr:      0           p_flags:    [ PF_X PF_W PF_R ]
>     p_paddr:      0           p_type:     [ PT_LOAD ]
>     p_filesz:     0x2bc1f     p_memsz:    0x2d6c8
>     p_offset:     0           p_align:    0x8000
> 
> Why linker is generating this type of header?

I am not sure exactly what you are asking here.  This header is needed because 
it is part of the ELF specification.  All loadable ELF binary files (ie either 
libraries or programs) have a header like this.

> But whenever I separate code and data segment this gives segmentation fault
> inside self relocation of run time linker.

It sounds like there is a problem inside the run time linker then.

> I am using gnu arm toolchain

Are you using the latest version ?  If not then try that.  Also try building a 
toolchain from the current mainline development sources as this *may* fix your 
problem.

> Could you please help me is this due to permiison of data segment or I have
> some other problem as in creating wrong data segment etc.

Could be.  You would need to investigate this "run time linker" you refer to.

> could you please explian me p_vaddr Vs p_paddr.

See the ELF spec for full details.  Here is a quick excerpt:

   p_vaddr
         This member gives the virtual address at which the first byte of
         the segment resides in memory.

   p_paddr
         On systems for which physical addressing is relevant, this member
         is reserved for the segment's physical address. This member
         requires operating system specific information, which is described
         in the appendix at the end of Book III.

Cheers
   Nick

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Regarding linker code generation
  2007-08-01 17:38   ` Nick Clifton
@ 2007-08-02  1:21     ` Bhushan Verma
  2007-08-06 15:28       ` Nick Clifton
  0 siblings, 1 reply; 8+ messages in thread
From: Bhushan Verma @ 2007-08-02  1:21 UTC (permalink / raw)
  To: Nick Clifton; +Cc: binutils

Thanks Nick,

I am using gnu arm tool chain 4.1.1.
I mean that when I build any shared object this toolchain is building only
one segment as below
 Program Header[0]:
     p_vaddr:      0           p_flags:    [ PF_X PF_W PF_R ]
     p_paddr:      0           p_type:     [ PT_LOAD ]
     p_filesz:     0x2bc1f     p_memsz:    0x2d6c8
     p_offset:     0           p_align:    0x8000

I know this header is needed ,but as per my knowledge this would make two
segment of p_type:PT_LOAD type.
mean two header values Program Header[0]: and  Program Header[1]: of
p_type:PT_LOAD, one for data segment and one for text segment.
why this tool chain only generate one segment . is there any thing wrong in
tool chain.

When I tried gcc3.2.2 tool chain on Linux then this makes two header.
I do not know why gcc 4.1.1 tool chain is not making two header values.


regards
verma

-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com]
Sent: Thursday, August 02, 2007 2:39 AM
To: Bhushan Verma
Cc: binutils@sourceware.org
Subject: Re: Regarding linker code generation


Hi Verma,

> Program Header[0]:
>     p_vaddr:      0           p_flags:    [ PF_X PF_W PF_R ]
>     p_paddr:      0           p_type:     [ PT_LOAD ]
>     p_filesz:     0x2bc1f     p_memsz:    0x2d6c8
>     p_offset:     0           p_align:    0x8000
>
> Why linker is generating this type of header?

I am not sure exactly what you are asking here.  This header is needed
because
it is part of the ELF specification.  All loadable ELF binary files (ie
either
libraries or programs) have a header like this.

> But whenever I separate code and data segment this gives segmentation
fault
> inside self relocation of run time linker.

It sounds like there is a problem inside the run time linker then.

> I am using gnu arm toolchain

Are you using the latest version ?  If not then try that.  Also try building
a
toolchain from the current mainline development sources as this *may* fix
your
problem.

> Could you please help me is this due to permiison of data segment or I
have
> some other problem as in creating wrong data segment etc.

Could be.  You would need to investigate this "run time linker" you refer
to.

> could you please explian me p_vaddr Vs p_paddr.

See the ELF spec for full details.  Here is a quick excerpt:

   p_vaddr
         This member gives the virtual address at which the first byte of
         the segment resides in memory.

   p_paddr
         On systems for which physical addressing is relevant, this member
         is reserved for the segment's physical address. This member
         requires operating system specific information, which is described
         in the appendix at the end of Book III.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Regarding linker code generation
  2007-08-02  1:21     ` Bhushan Verma
@ 2007-08-06 15:28       ` Nick Clifton
  2007-08-13  7:45         ` Bhushan Verma
  0 siblings, 1 reply; 8+ messages in thread
From: Nick Clifton @ 2007-08-06 15:28 UTC (permalink / raw)
  To: Bhushan Verma; +Cc: binutils

Hi Verma,

> I am using gnu arm tool chain 4.1.1.

Which version of the linker is used with this toolchain ?  If it is a version 
earlier than 2.17 then it would be worth your while downloading the current 
binutils sources and building your own linker.


> I mean that when I build any shared object this toolchain is building only
> one segment as below
>  Program Header[0]:
>      p_vaddr:      0           p_flags:    [ PF_X PF_W PF_R ]
>      p_paddr:      0           p_type:     [ PT_LOAD ]
>      p_filesz:     0x2bc1f     p_memsz:    0x2d6c8
>      p_offset:     0           p_align:    0x8000
> 
> I know this header is needed ,but as per my knowledge this would make two
> segment of p_type:PT_LOAD type.
> mean two header values Program Header[0]: and  Program Header[1]: of
> p_type:PT_LOAD, one for data segment and one for text segment.
> why this tool chain only generate one segment . is there any thing wrong in
> tool chain.

Two segments are not essential.  One segment is sufficient, although possibly 
less efficient.  ie it is not required that data sections are placed in a 
read-only segment.  It is probably better to do so, but it is not required.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Regarding linker code generation
  2007-08-06 15:28       ` Nick Clifton
@ 2007-08-13  7:45         ` Bhushan Verma
  2007-08-31 20:53           ` Nick Clifton
  0 siblings, 1 reply; 8+ messages in thread
From: Bhushan Verma @ 2007-08-13  7:45 UTC (permalink / raw)
  To: Nick Clifton; +Cc: binutils

Thanks Mr. Nick,

I am using 2.17 linker version.
I do know know how this is happening?
There can be some environment problem.

regards
verma

-----Original Message-----
From: binutils-owner@sourceware.org [mailto:binutils-owner@sourceware.org]On
Behalf Of Nick Clifton
Sent: Tuesday, August 07, 2007 12:28 AM
To: Bhushan Verma
Cc: binutils@sourceware.org
Subject: Re: Regarding linker code generation


Hi Verma,

> I am using gnu arm tool chain 4.1.1.

Which version of the linker is used with this toolchain ?  If it is a
version
earlier than 2.17 then it would be worth your while downloading the current
binutils sources and building your own linker.


> I mean that when I build any shared object this toolchain is building only
> one segment as below
>  Program Header[0]:
>      p_vaddr:      0           p_flags:    [ PF_X PF_W PF_R ]
>      p_paddr:      0           p_type:     [ PT_LOAD ]
>      p_filesz:     0x2bc1f     p_memsz:    0x2d6c8
>      p_offset:     0           p_align:    0x8000
>
> I know this header is needed ,but as per my knowledge this would make two
> segment of p_type:PT_LOAD type.
> mean two header values Program Header[0]: and  Program Header[1]: of
> p_type:PT_LOAD, one for data segment and one for text segment.
> why this tool chain only generate one segment . is there any thing wrong
in
> tool chain.

Two segments are not essential.  One segment is sufficient, although
possibly
less efficient.  ie it is not required that data sections are placed in a
read-only segment.  It is probably better to do so, but it is not required.

Cheers
   Nick



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Regarding linker code generation
  2007-08-13  7:45         ` Bhushan Verma
@ 2007-08-31 20:53           ` Nick Clifton
  2007-09-04  8:23             ` Bhushan Verma
  0 siblings, 1 reply; 8+ messages in thread
From: Nick Clifton @ 2007-08-31 20:53 UTC (permalink / raw)
  To: Bhushan Verma; +Cc: binutils

Hi Bhushan,

> I am using 2.17 linker version.
> I do know know how this is happening?
> There can be some environment problem.

Possibly.  Please could you generate a simple test case that demonstrates this 
problem, so that we can investigate it ?

Cheers
   Nick

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: Regarding linker code generation
  2007-08-31 20:53           ` Nick Clifton
@ 2007-09-04  8:23             ` Bhushan Verma
  2007-09-07 15:38               ` Nick Clifton
  0 siblings, 1 reply; 8+ messages in thread
From: Bhushan Verma @ 2007-09-04  8:23 UTC (permalink / raw)
  To: Nick Clifton; +Cc: binutils

Dear  Nick,

We got the solution  that generate separate code and data segment by
updating tool chain.
Since someone build this tool chain now this is rebuild .I think there was
some problem in building tool chain.

Now problem is that we are unable to give the execute permission (RWX) to
data segment.
This is requirement for  run time linker.
Could you please help me how can I do this ,is there any provision to change
the default linker script.
I mean how can I change default linker script which gives execute permission
to linker.


Regards
Bhushan



-----Original Message-----
From: Nick Clifton [mailto:nickc@redhat.com]
Sent: Saturday, September 01, 2007 12:24 AM
To: Bhushan Verma
Cc: binutils@sourceware.org
Subject: Re: Regarding linker code generation


Hi Bhushan,

> I am using 2.17 linker version.
> I do know know how this is happening?
> There can be some environment problem.

Possibly.  Please could you generate a simple test case that demonstrates
this
problem, so that we can investigate it ?

Cheers
   Nick


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Regarding linker code generation
  2007-09-04  8:23             ` Bhushan Verma
@ 2007-09-07 15:38               ` Nick Clifton
  0 siblings, 0 replies; 8+ messages in thread
From: Nick Clifton @ 2007-09-07 15:38 UTC (permalink / raw)
  To: Bhushan Verma; +Cc: binutils

Hi Bhushan,

> Now problem is that we are unable to give the execute permission (RWX) to
> data segment.  This is requirement for  run time linker.

An unusual requirement, but OK...

> Could you please help me how can I do this ,is there any provision to change
> the default linker script.

Yes.  The -T command line switch to the linker (or to gcc) will override the 
default linker script and let you specify your own script.

Here is one way of doing this:

   1.  Run "ld --verbose" and save the output.  This gives you a copy of the 
built-in, default linker script.  You will need to edit the output to remove a 
few lines of text at the beginning and end of the output.

   2.  Read the linker manual's section on linker scripts and in particular the 
part about defining your segments.  Then add a set of segment definitions to 
your new linker script.  For example I used this:

   PHDRS
   {
     exec_data PT_LOAD  FLAGS (7) ;
     code      PT_LOAD  FLAGS (5) ;
     data      PT_LOAD  FLAGS (6) ;
   }

   3. Now you can annotate the entries in the SECTIONS part of the linker 
script with the segment that you want them to use.  eg:

    .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } :exec_data

You may need to experiment a bit but you should be able to achieve the results 
you want.

Cheers
   Nick

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-09-07 15:38 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1185763943.19324.ezmlm@sourceware.org>
2007-07-30 14:24 ` Regarding linker code generation Bhushan Verma
2007-08-01 17:38   ` Nick Clifton
2007-08-02  1:21     ` Bhushan Verma
2007-08-06 15:28       ` Nick Clifton
2007-08-13  7:45         ` Bhushan Verma
2007-08-31 20:53           ` Nick Clifton
2007-09-04  8:23             ` Bhushan Verma
2007-09-07 15:38               ` Nick Clifton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).