This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Make global file function names link unique

On Thu, Dec 14, 2006 at 05:25:48PM -0800, Geoffrey Keating wrote:
> On 14/12/2006, at 5:09 PM, John David Anglin wrote:
> >The use of crc32_string to create a unique file name is a compromise,
> >and there's a very small probability that it might conflict with a
> >user selected name or not yield a link unique name.  However, I don't
> >think any solution is perfect.  An advantages of using crc32_string
> >over the file's basename is that it's limited in length and doesn't
> >need any cleanup.
> I think your problem is that 'first_global_object_name' is supposed to  
> be a name unique to this file, and you have found a case where it  
> isn't.  It would be better if you could ensure that  
> first_global_object_name was really a name unique to this file.   
> ("unique to this file" means "only this file in the whole link can be  
> defining this symbol".)

Well, there's no way to guarantee that first_global_object_name
is unique in the sense that "only this file in the whole link can be
defining this symbol".  It's fairly likely that the compiler will
pick the same symbol when a global symbol in a shared libraries is
overloaded.  This shouldn't be ignored since there's no way to know
that the compiler has generated incorrect code until an incorrect
result is generated.

> If you can't guarantee that any name is unique to this file, you need  
> to fall down to the last case in this function, where it already does  
> all kinds of crc32 operations.  If you're going to do that, or do  
> something like what you have in the patch below, please only do it on  
> targets that actually need it.

The 'F' type is only used on targets where eh_frame_section is null.
So, if type 'F' is used, it needs to be unique for the whole link.
Same appears to be true for 'N' since is only used when 
! flag_weak || ! SUPPORTS_ONE_ONLY is true.  For 'I' and 'D', I'm
not sure.  It is clear that the current code results in duplicates.
Possibly, !targetm.have_ctors_dtors is the condition.

I don't agree that we should automatically fall down to the last
case because it's better to use the first_global_object_name as a
start than the weak_global_object_name or the main_input_filename.
The whole point of the patch was to make the name "unique to this
file" when starting with the first_global_object_name.

J. David Anglin                        
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]