excessive stab information
Andy Chittenden
AChittenden@bluearc.com
Thu Apr 28 15:42:00 GMT 2005
More information about the Binutils mailing list
Thu Apr 28 15:42:00 GMT 2005
- Previous message (by thread): excessive stab information
- Next message (by thread): excessive stab information
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > ... Second, it seems to me that it will > > slow down a stabs link slightly, ... for us, it did speed it up a little! > > ... Most people do not refer to the same header file using two > > different names. This comes about as we "publish" headers that define public interfaces to subsystems into a "public" directory that other subsystems can #include from. We do this via symlinks. The "duplicate" stabs come about by virtue of the publishing directory finding the original header and the using directory using the published one. This is not the first environment in which I've seen this technique used. > > I don't think it's a good idea even then. It assumes that > the paths in > stabs refer to files on the system where the linker is running. ... but that's a danger with the existing scheme without using realpath. Given that the symbols within the BINCL would have to match exactly to get duplicate stab suppression, I don't see that as a problem. -- Andy, BlueArc Engineering
- Previous message (by thread): excessive stab information
- Next message (by thread): excessive stab information
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list