* RFC: Disallow protected data symbol with copy relocation? @ 2005-01-21 4:57 H. J. Lu 2005-01-21 5:07 ` Ian Lance Taylor 0 siblings, 1 reply; 10+ messages in thread From: H. J. Lu @ 2005-01-21 4:57 UTC (permalink / raw) To: binutils; +Cc: gcc, hongjiu.lu Protected data symbol with copy relocation never works as intended. The problem is with copy relocation, main and DSO see different copies of the protected data symbol. Updating one won't change the other. You can't compare their addresses either. There is no easy way to get it to work unless the psABI is changed. I am proposing to make linker to reject protected data symbol with copy relocation. Any comments? H.J. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Disallow protected data symbol with copy relocation? 2005-01-21 4:57 RFC: Disallow protected data symbol with copy relocation? H. J. Lu @ 2005-01-21 5:07 ` Ian Lance Taylor 2005-01-21 5:18 ` H. J. Lu 0 siblings, 1 reply; 10+ messages in thread From: Ian Lance Taylor @ 2005-01-21 5:07 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils, gcc, hongjiu.lu "H. J. Lu" <hjl@lucon.org> writes: > Protected data symbol with copy relocation never works as intended. > The problem is with copy relocation, main and DSO see different > copies of the protected data symbol. Updating one won't change > the other. You can't compare their addresses either. There is no > easy way to get it to work unless the psABI is changed. I am proposing > to make linker to reject protected data symbol with copy relocation. > Any comments? Why would the linker ever generate a copy relocation for a protected symbol? I don't see how that makes sense. Ian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Disallow protected data symbol with copy relocation? 2005-01-21 5:07 ` Ian Lance Taylor @ 2005-01-21 5:18 ` H. J. Lu 2005-01-21 5:46 ` Ian Lance Taylor 0 siblings, 1 reply; 10+ messages in thread From: H. J. Lu @ 2005-01-21 5:18 UTC (permalink / raw) To: binutils, gcc, hongjiu.lu On Fri, Jan 21, 2005 at 12:07:01AM -0500, Ian Lance Taylor wrote: > "H. J. Lu" <hjl@lucon.org> writes: > > > Protected data symbol with copy relocation never works as intended. > > The problem is with copy relocation, main and DSO see different > > copies of the protected data symbol. Updating one won't change > > the other. You can't compare their addresses either. There is no > > easy way to get it to work unless the psABI is changed. I am proposing > > to make linker to reject protected data symbol with copy relocation. > > Any comments? > > Why would the linker ever generate a copy relocation for a protected > symbol? I don't see how that makes sense. > For some psABIs, copy relocation is the normal way for main to access data symbol on DSO. On ia32, you may generate writable text section to work around it or compile main with PIC to avoid copy relocation. But on x86_64, you may have to compile main with PIC. H.J. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Disallow protected data symbol with copy relocation? 2005-01-21 5:18 ` H. J. Lu @ 2005-01-21 5:46 ` Ian Lance Taylor 2005-01-21 5:52 ` H. J. Lu 0 siblings, 1 reply; 10+ messages in thread From: Ian Lance Taylor @ 2005-01-21 5:46 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils, gcc, hongjiu.lu "H. J. Lu" <hjl@lucon.org> writes: > > Why would the linker ever generate a copy relocation for a protected > > symbol? I don't see how that makes sense. > > > > For some psABIs, copy relocation is the normal way for main to access > data symbol on DSO. > ... Yes, I know. But clearly a copy relocation can not work. We should treat this case as though -z nocopyreloc was used for that specific symbol. Maybe that is what you meant by "reject protected data symbol with copy relocation." I am saying that the answer is not to reject the symbol, it is to not generate the copy relocation. There may be specific targets and/or cases where -z nocopyreloc does not work, for some hideous reason. Those specific targets and/or cases should generate a specific error. But this is not a general problem. Ian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Disallow protected data symbol with copy relocation? 2005-01-21 5:46 ` Ian Lance Taylor @ 2005-01-21 5:52 ` H. J. Lu 2005-01-21 6:26 ` Ian Lance Taylor 0 siblings, 1 reply; 10+ messages in thread From: H. J. Lu @ 2005-01-21 5:52 UTC (permalink / raw) To: binutils, gcc, hongjiu.lu On Fri, Jan 21, 2005 at 12:46:26AM -0500, Ian Lance Taylor wrote: > "H. J. Lu" <hjl@lucon.org> writes: > > > > Why would the linker ever generate a copy relocation for a protected > > > symbol? I don't see how that makes sense. > > > > > > > For some psABIs, copy relocation is the normal way for main to access > > data symbol on DSO. > > ... > > Yes, I know. But clearly a copy relocation can not work. We should > treat this case as though -z nocopyreloc was used for that specific > symbol. > > Maybe that is what you meant by "reject protected data symbol with > copy relocation." I am saying that the answer is not to reject the > symbol, it is to not generate the copy relocation. Avoid copy relocation leads to writable text section on ia32. I am not sure that generate writable text section without -z nocopyreloc is a good idea. > > There may be specific targets and/or cases where -z nocopyreloc does > not work, for some hideous reason. Those specific targets and/or > cases should generate a specific error. But this is not a general > problem. I don't think -z nocopyreloc works on x86_64. H.J. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Disallow protected data symbol with copy relocation? 2005-01-21 5:52 ` H. J. Lu @ 2005-01-21 6:26 ` Ian Lance Taylor 2005-01-21 6:45 ` H. J. Lu 0 siblings, 1 reply; 10+ messages in thread From: Ian Lance Taylor @ 2005-01-21 6:26 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils, gcc, hongjiu.lu "H. J. Lu" <hjl@lucon.org> writes: > Avoid copy relocation leads to writable text section on ia32. I am not > sure that generate writable text section without -z nocopyreloc is a > good idea. I don't see why it is better to prevent the user from generating an executable at all. What this is really leading up to is that it is unwise for a shared library to declare a global variable to be protected. Doing that makes it costly for the main executable to refer to that global variable. But if a shared library does declare a global variable to be protected, and if the main executable does refer to it, I think we should attempt to support that. I don't see why we should simply reject it and make it impossible to use the shared library in that way. We could perhaps issue a warning in that case. > I don't think -z nocopyreloc works on x86_64. Can it be fixed, or is there some reason that it is impossible? Ian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Disallow protected data symbol with copy relocation? 2005-01-21 6:26 ` Ian Lance Taylor @ 2005-01-21 6:45 ` H. J. Lu 2005-01-22 1:33 ` RFC: Properly handle protected data symbol with copy relocation H. J. Lu 0 siblings, 1 reply; 10+ messages in thread From: H. J. Lu @ 2005-01-21 6:45 UTC (permalink / raw) To: binutils, gcc, hongjiu.lu On Fri, Jan 21, 2005 at 01:26:06AM -0500, Ian Lance Taylor wrote: > "H. J. Lu" <hjl@lucon.org> writes: > > > Avoid copy relocation leads to writable text section on ia32. I am not > > sure that generate writable text section without -z nocopyreloc is a > > good idea. > > I don't see why it is better to prevent the user from generating an > executable at all. > > What this is really leading up to is that it is unwise for a shared > library to declare a global variable to be protected. Doing that > makes it costly for the main executable to refer to that global > variable. > > But if a shared library does declare a global variable to be > protected, and if the main executable does refer to it, I think we > should attempt to support that. I don't see why we should simply > reject it and make it impossible to use the shared library in that > way. We could perhaps issue a warning in that case. I see. For ia32, we can issue a warning when generating such a shared library and generate writable text section when it is referenced by main executable. > > > I don't think -z nocopyreloc works on x86_64. > > Can it be fixed, or is there some reason that it is impossible? > I think it has something to do with the psABI and Linux runtime, something like relocation is 32bit and main/DSO are several GB apart. For x86_64, we can warn it when creating such a shared library and refuse to link if it is referenced by main. H.J. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RFC: Properly handle protected data symbol with copy relocation 2005-01-21 6:45 ` H. J. Lu @ 2005-01-22 1:33 ` H. J. Lu 2005-01-24 19:48 ` Ian Lance Taylor 0 siblings, 1 reply; 10+ messages in thread From: H. J. Lu @ 2005-01-22 1:33 UTC (permalink / raw) To: binutils, gcc On Thu, Jan 20, 2005 at 10:45:13PM -0800, H. J. Lu wrote: > On Fri, Jan 21, 2005 at 01:26:06AM -0500, Ian Lance Taylor wrote: > > "H. J. Lu" <hjl@lucon.org> writes: > > > > > Avoid copy relocation leads to writable text section on ia32. I am not > > > sure that generate writable text section without -z nocopyreloc is a > > > good idea. > > > > I don't see why it is better to prevent the user from generating an > > executable at all. > > > > What this is really leading up to is that it is unwise for a shared > > library to declare a global variable to be protected. Doing that > > makes it costly for the main executable to refer to that global > > variable. > > > > But if a shared library does declare a global variable to be > > protected, and if the main executable does refer to it, I think we > > should attempt to support that. I don't see why we should simply > > reject it and make it impossible to use the shared library in that > > way. We could perhaps issue a warning in that case. > > I see. For ia32, we can issue a warning when generating such a shared > library and generate writable text section when it is referenced by > main executable. > > > > > > > I don't think -z nocopyreloc works on x86_64. > > > > Can it be fixed, or is there some reason that it is impossible? > > > > I think it has something to do with the psABI and Linux runtime, > something like relocation is 32bit and main/DSO are several GB > apart. For x86_64, we can warn it when creating such a shared > library and refuse to link if it is referenced by main. > This is my proposal. H.J. ----- There is a problem on ia32 and x86_64, where copy relocation is used to allow main executable to access data variables in DSO. Normally, linker will create a copy relocation when main references a data variable in DSO. At the runtime, dynamic linker will create a copy of the data variable from DSO to the address space of main. It will arrange both DSO and main to access the copy in main instead of the original one in DSO. When a data variable in DSO is marked protected, DSO will always use the original one it has and main will use the copy. Now, main and DSO will see 2 different ones even though the one in main is just a copy of the original one. I am proposing 1. For ia32, when creating a shared library with a protected data variable, we warn that the resulting DSO will lead to main executable to be compiled with PIC or be generated with writable text section when the data variable is accessed. Linker will issue a warning when a main executable is made with writable text section because of it. 2. For x86_64, when creating a shared library a protected data variable, we warn that the resulting DSO will lead to main executable to be compiled with PIC when the data variable is referenced. Linker will issue an error when a main executable references a protected data symbol with R_X86_64_PC32 since main and DSO may be more than 2GB apart. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Properly handle protected data symbol with copy relocation 2005-01-22 1:33 ` RFC: Properly handle protected data symbol with copy relocation H. J. Lu @ 2005-01-24 19:48 ` Ian Lance Taylor 2005-01-24 22:32 ` Alan Modra 0 siblings, 1 reply; 10+ messages in thread From: Ian Lance Taylor @ 2005-01-24 19:48 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils, gcc "H. J. Lu" <hjl@lucon.org> writes: > I am proposing > > 1. For ia32, when creating a shared library with a protected data > variable, we warn that the resulting DSO will lead to main executable > to be compiled with PIC or be generated with writable text section when > the data variable is accessed. Linker will issue a warning when a main > executable is made with writable text section because of it. > 2. For x86_64, when creating a shared library a protected data > variable, we warn that the resulting DSO will lead to main executable > to be compiled with PIC when the data variable is referenced. Linker > will issue an error when a main executable references a protected data > symbol with R_X86_64_PC32 since main and DSO may be more than 2GB > apart. Seems more or less reasonable. I still don't understand why x86_64 can't simply use a writable text section. I understand that it doesn't do it; I don't understand why it can't do it. Ian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RFC: Properly handle protected data symbol with copy relocation 2005-01-24 19:48 ` Ian Lance Taylor @ 2005-01-24 22:32 ` Alan Modra 0 siblings, 0 replies; 10+ messages in thread From: Alan Modra @ 2005-01-24 22:32 UTC (permalink / raw) To: binutils, gcc, hjl On Mon, Jan 24, 2005 at 02:47:50PM -0500, Ian Lance Taylor wrote: > "H. J. Lu" <hjl@lucon.org> writes: > Seems more or less reasonable. I still don't understand why x86_64 > can't simply use a writable text section. I understand that it > doesn't do it; I don't understand why it can't do it. The problem is that x86_64 uses a 64-bit address space, so 32-bit pc-relative relocations in the executable may not be able to reach into a shared library. -- Alan Modra IBM OzLabs - Linux Technology Centre ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-01-24 22:32 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-21 4:57 RFC: Disallow protected data symbol with copy relocation? H. J. Lu 2005-01-21 5:07 ` Ian Lance Taylor 2005-01-21 5:18 ` H. J. Lu 2005-01-21 5:46 ` Ian Lance Taylor 2005-01-21 5:52 ` H. J. Lu 2005-01-21 6:26 ` Ian Lance Taylor 2005-01-21 6:45 ` H. J. Lu 2005-01-22 1:33 ` RFC: Properly handle protected data symbol with copy relocation H. J. Lu 2005-01-24 19:48 ` Ian Lance Taylor 2005-01-24 22:32 ` Alan Modra
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).