* 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).