* Changing .dynstr to be more C++ friendly? @ 2005-02-24 1:11 Chris Kirby 2005-02-24 13:15 ` MIPS gas doesn't set SH_FLAG Brett Porter 2005-02-24 13:58 ` Changing .dynstr to be more C++ friendly? Alan Modra 0 siblings, 2 replies; 10+ messages in thread From: Chris Kirby @ 2005-02-24 1:11 UTC (permalink / raw) To: binutils We have a large C++ embedded project where we have some large (~7MB) .dynstr sections that are taking up a lot of memory. I used objdump to dump out all of the dynamic strings, and I noticed two C++ features that contributed to the large string size: 1) namespaces and class names are at the front of the mangled symbol name 2) templates with multiple instantiations Looking at the strings, I noticed that there are possibilities for compression: - For functions in the same namespace / class (#1), they tended to have a common prefix. - For instantiated templates (#2), they tended to end with the same suffix since they implement similar functions. My thinking was that we could change the definition of an Elf symbol to not contain a single name, but rather N distinct name components (3 in this case). Using the example above, we could use the first for the prefix, the second for the unique portion, and the third for the suffix. The hope would be that the prefix and suffix strings would be shared across multiple symbols. For C++ applications I think the compression possible would be fairly high. How difficult do you think it would it be to add these additional strings to the elf symbol table entries? - Chris Kirby ^ permalink raw reply [flat|nested] 10+ messages in thread
* MIPS gas doesn't set SH_FLAG 2005-02-24 1:11 Changing .dynstr to be more C++ friendly? Chris Kirby @ 2005-02-24 13:15 ` Brett Porter 2005-02-28 19:38 ` Nick Clifton 2005-02-24 13:58 ` Changing .dynstr to be more C++ friendly? Alan Modra 1 sibling, 1 reply; 10+ messages in thread From: Brett Porter @ 2005-02-24 13:15 UTC (permalink / raw) To: binutils Here is a rather simple program: .section .debug_frame,0x7000001e,0x8000000,0,4 .byte 0 I'm trying to assemble it on an IRIX64 6.5 system with a recently released gas and with gas built from snapshot sources dated today. That section flag bit is for SHF_MIPS_NOSTRIP. elfdump shows that it isn't set in the output file. It is set when assembled with the IRIX assembler. I bumped into this one -- didn't go hunting for other flags... Is this a simple missing piece or part of a bigger, messier puzzle, or ??? Thanks, Brett ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MIPS gas doesn't set SH_FLAG 2005-02-24 13:15 ` MIPS gas doesn't set SH_FLAG Brett Porter @ 2005-02-28 19:38 ` Nick Clifton 2005-03-01 1:18 ` Eric Christopher 0 siblings, 1 reply; 10+ messages in thread From: Nick Clifton @ 2005-02-28 19:38 UTC (permalink / raw) To: Brett Porter, Eric Christopher, seufer; +Cc: binutils Hi Brett, Hi Eric, Hi Thiemo, > Brett Porter wrote: > Here is a rather simple program: > > .section .debug_frame,0x7000001e,0x8000000,0,4 > .byte 0 > > I'm trying to assemble it on an IRIX64 6.5 system with a recently > released gas and with gas built from snapshot sources dated today. > > That section flag bit is for SHF_MIPS_NOSTRIP. elfdump shows that > it isn't set in the output file. It is set when assembled with the > IRIX assembler. I bumped into this one -- didn't go hunting for > other flags... > > Is this a simple missing piece or part of a bigger, messier puzzle, > or ??? It is a bigger, messier puzzle in that no MIPS specific ELF section header flags can (currently) be set via the .section directive. The MIPS port of GAS does have special code to handle setting other section header flags via the .section directive, so I am assuming that the intent was that MIPS specific flags would be supported too. Hence I am offering up the attached patch as a possible solution. Eric, Thiemo - what do you think ? Tested with no regressions on mips-elf, mips64-linux-gnu and mipsisa32el-linux-gnu targets. Note - as an aside I noticed that readelf does not currently decode and display the values of MIPS specific section flags - it probably should do this, if somebody wanted to write the code... Cheers Nick bfd/ChangeLog 2005-02-28 Nick Clifton <nickc@redhat.com> * elfxx-mips.c (_bfd_mips_elf_fake_sections): Copy user specified, MIPS specific section flags into the fake section's header. gas/ChangeLog 2005-02-28 Nick Clifton <nickc@redhat.com> * config/tc-mips.c (mips_elf_section_flags): New function. Ensure that user specified MIPS specific section flags are permitted in the section header. * config/tc-mips.h (md_elf_section_flags): Define. Use mips_elf_section_flags. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MIPS gas doesn't set SH_FLAG 2005-02-28 19:38 ` Nick Clifton @ 2005-03-01 1:18 ` Eric Christopher 2005-03-01 9:47 ` Nick Clifton 0 siblings, 1 reply; 10+ messages in thread From: Eric Christopher @ 2005-03-01 1:18 UTC (permalink / raw) To: Nick Clifton; +Cc: Brett Porter, seufer, binutils > Hence I am offering up the attached patch as a possible solution. Eric, > Thiemo - what do you think ? Tested with no regressions on mips-elf, > mips64-linux-gnu and mipsisa32el-linux-gnu targets. > > bfd/ChangeLog > 2005-02-28 Nick Clifton <nickc@redhat.com> > > * elfxx-mips.c (_bfd_mips_elf_fake_sections): Copy user specified, > MIPS specific section flags into the fake section's header. > > gas/ChangeLog > 2005-02-28 Nick Clifton <nickc@redhat.com> > > * config/tc-mips.c (mips_elf_section_flags): New function. Ensure > that user specified MIPS specific section flags are permitted in > the section header. > * config/tc-mips.h (md_elf_section_flags): Define. Use > mips_elf_section_flags. ChangeLogs look good, how about that patch? :) -eric ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MIPS gas doesn't set SH_FLAG 2005-03-01 1:18 ` Eric Christopher @ 2005-03-01 9:47 ` Nick Clifton 2005-03-01 16:38 ` Brett Porter 2005-03-01 17:27 ` Eric Christopher 0 siblings, 2 replies; 10+ messages in thread From: Nick Clifton @ 2005-03-01 9:47 UTC (permalink / raw) To: Eric Christopher; +Cc: Brett Porter, seufer, binutils [-- Attachment #1: Type: text/plain, Size: 175 bytes --] Hi Eric, Hi Brett, Hi Thiemo, > ChangeLogs look good, how about that patch? :) I could have sworn that I attached the file. Oh well... Here it is again. Cheers Nick [-- Attachment #2: mips.patch --] [-- Type: text/plain, Size: 2999 bytes --] Index: bfd/elfxx-mips.c =================================================================== RCS file: /cvs/src/src/bfd/elfxx-mips.c,v retrieving revision 1.124 diff -c -3 -p -r1.124 elfxx-mips.c *** bfd/elfxx-mips.c 23 Feb 2005 11:39:14 -0000 1.124 --- bfd/elfxx-mips.c 28 Feb 2005 17:01:12 -0000 *************** _bfd_mips_elf_fake_sections (bfd *abfd, *** 4578,4583 **** --- 4578,4587 ---- name = bfd_get_section_name (abfd, sec); + /* If the user has specified any MIPS specific + flags then make sure that they are propogated. */ + hdr->sh_flags |= (sec->flags & (SHF_MASKOS | SHF_MASKPROC)); + if (strcmp (name, ".liblist") == 0) { hdr->sh_type = SHT_MIPS_LIBLIST; Index: gas/config/tc-mips.c =================================================================== RCS file: /cvs/src/src/gas/config/tc-mips.c,v retrieving revision 1.287 diff -c -3 -p -r1.287 tc-mips.c *** gas/config/tc-mips.c 23 Feb 2005 12:28:04 -0000 1.287 --- gas/config/tc-mips.c 28 Feb 2005 17:01:16 -0000 *************** s_change_section (int ignore ATTRIBUTE_U *** 11385,11398 **** --- 11385,11401 ---- section_type = get_absolute_expression (); else section_type = 0; + if (*input_line_pointer++ == ',') section_flag = get_absolute_expression (); else section_flag = 0; + if (*input_line_pointer++ == ',') section_entry_size = get_absolute_expression (); else section_entry_size = 0; + if (*input_line_pointer++ == ',') section_alignment = get_absolute_expression (); else *************** s_change_section (int ignore ATTRIBUTE_U *** 11424,11429 **** --- 11427,11447 ---- #endif /* OBJ_ELF */ } + #ifdef OBJ_ELF + /* Ensure that any MIPS specific flags in ATTR are passed + on to FLAGS. */ + + int + mips_elf_section_flags (flagword flags, int attr) + { + /* Strictly speaking we ought to only select those bits in the OS and PROC + specific sections of the flags which we know to have defined meanings + for the MIPS. But using the masks is easier and will prevent stange + bugs when new flags are added but this code is not updated. */ + return flags | (attr & (SHF_MASKPROC | SHF_MASKOS)); + } + #endif /* OBJ_ELF */ + void mips_enable_auto_align (void) { Index: gas/config/tc-mips.h =================================================================== RCS file: /cvs/src/src/gas/config/tc-mips.h,v retrieving revision 1.35 diff -c -3 -p -r1.35 tc-mips.h *** gas/config/tc-mips.h 29 Apr 2004 05:14:22 -0000 1.35 --- gas/config/tc-mips.h 28 Feb 2005 17:01:16 -0000 *************** extern unsigned long mips_cprmask[4]; *** 150,155 **** --- 150,158 ---- #define elf_tc_final_processing mips_elf_final_processing extern void mips_elf_final_processing (void); + #define md_elf_section_flags(FLAGS, ATTR, TYPE) \ + mips_elf_section_flags ((FLAGS), (ATTR)) + extern int mips_elf_section_flags (flagword, int); #endif extern void md_mips_end (void); ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MIPS gas doesn't set SH_FLAG 2005-03-01 9:47 ` Nick Clifton @ 2005-03-01 16:38 ` Brett Porter 2005-03-01 17:27 ` Eric Christopher 1 sibling, 0 replies; 10+ messages in thread From: Brett Porter @ 2005-03-01 16:38 UTC (permalink / raw) To: Nick Clifton; +Cc: Eric Christopher, seufer, binutils Thanks Nick. I've applied your patch and done a little testing -- it looks good. Brett ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: MIPS gas doesn't set SH_FLAG 2005-03-01 9:47 ` Nick Clifton 2005-03-01 16:38 ` Brett Porter @ 2005-03-01 17:27 ` Eric Christopher 1 sibling, 0 replies; 10+ messages in thread From: Eric Christopher @ 2005-03-01 17:27 UTC (permalink / raw) To: Nick Clifton; +Cc: Brett Porter, seufer, binutils On Tue, 2005-03-01 at 09:59 +0000, Nick Clifton wrote: > Hi Eric, Hi Brett, Hi Thiemo, > > > ChangeLogs look good, how about that patch? :) > > > I could have sworn that I attached the file. Oh well... Here it is again. Sure. This is great, thanks. -eric ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Changing .dynstr to be more C++ friendly? 2005-02-24 1:11 Changing .dynstr to be more C++ friendly? Chris Kirby 2005-02-24 13:15 ` MIPS gas doesn't set SH_FLAG Brett Porter @ 2005-02-24 13:58 ` Alan Modra 2005-02-24 17:14 ` Chris Kirby 1 sibling, 1 reply; 10+ messages in thread From: Alan Modra @ 2005-02-24 13:58 UTC (permalink / raw) To: Chris Kirby; +Cc: binutils On Wed, Feb 23, 2005 at 02:22:50PM -0500, Chris Kirby wrote: > We have a large C++ embedded project Personally, I don't think you should mention "embedded" and "C++" in the same breath. > My thinking was that we could change the definition of an Elf symbol > to not contain a single name, but rather N distinct name components > (3 in this case). I think you underestimate the scope of the change you are proposing. This would require changes to all consumers of ELF files, which means more than just the assembler and linker. Debuggers, ld.so, etc. -- Alan Modra IBM OzLabs - Linux Technology Centre ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Changing .dynstr to be more C++ friendly? 2005-02-24 13:58 ` Changing .dynstr to be more C++ friendly? Alan Modra @ 2005-02-24 17:14 ` Chris Kirby 2005-02-24 17:28 ` Daniel Jacobowitz 0 siblings, 1 reply; 10+ messages in thread From: Chris Kirby @ 2005-02-24 17:14 UTC (permalink / raw) To: Alan Modra; +Cc: binutils At 12:17 PM 2/24/2005 +1030, Alan Modra wrote: >On Wed, Feb 23, 2005 at 02:22:50PM -0500, Chris Kirby wrote: >> My thinking was that we could change the definition of an Elf symbol >> to not contain a single name, but rather N distinct name components >> (3 in this case). > >I think you underestimate the scope of the change you are proposing. >This would require changes to all consumers of ELF files, which means >more than just the assembler and linker. Debuggers, ld.so, etc. I was hoping that they all used bfd or liberty so we would only have to change it there. If everyone has there own code to interact with ELF files, then I agree it would be too large of a change to be feasible right now. If ELF is ever revised, it would be nice to consider ways to compress the dynamic strings for languages other than just C. For our embedded application, I am wondering how feasible it would be to change the symbol names to something shorter. As long as the application and the shared library are in agreement in what the symbol names are, it should not matter what they are. This would allow us to come up with a more compact naming scheme than the current C++ name mangler. I could imagine a post processing step after the application and libraries are built where the current names in use are found, converted to a shorter representation, and then replaced. - Chris ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Changing .dynstr to be more C++ friendly? 2005-02-24 17:14 ` Chris Kirby @ 2005-02-24 17:28 ` Daniel Jacobowitz 0 siblings, 0 replies; 10+ messages in thread From: Daniel Jacobowitz @ 2005-02-24 17:28 UTC (permalink / raw) To: Chris Kirby; +Cc: Alan Modra, binutils On Thu, Feb 24, 2005 at 09:52:12AM -0500, Chris Kirby wrote: > At 12:17 PM 2/24/2005 +1030, Alan Modra wrote: > >On Wed, Feb 23, 2005 at 02:22:50PM -0500, Chris Kirby wrote: > >> My thinking was that we could change the definition of an Elf symbol > >> to not contain a single name, but rather N distinct name components > >> (3 in this case). > > > >I think you underestimate the scope of the change you are proposing. > >This would require changes to all consumers of ELF files, which means > >more than just the assembler and linker. Debuggers, ld.so, etc. > > I was hoping that they all used bfd or liberty so we would only have > to change it there. If everyone has there own code to interact with > ELF files, then I agree it would be too large of a change to be > feasible right now. If ELF is ever revised, it would be nice to > consider ways to compress the dynamic strings for languages other > than just C. > > For our embedded application, I am wondering how feasible it would be > to change the symbol names to something shorter. As long as the > application and the shared library are in agreement in what the > symbol names are, it should not matter what they are. This would > allow us to come up with a more compact naming scheme than the > current C++ name mangler. I could imagine a post processing step > after the application and libraries are built where the current names > in use are found, converted to a shorter representation, and then > replaced. I don't know if this will interfere with any of the C++ support library functions, but you can probably make it work. It's not hard to rename symbols in an ELF file. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2005-03-01 17:27 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-02-24 1:11 Changing .dynstr to be more C++ friendly? Chris Kirby 2005-02-24 13:15 ` MIPS gas doesn't set SH_FLAG Brett Porter 2005-02-28 19:38 ` Nick Clifton 2005-03-01 1:18 ` Eric Christopher 2005-03-01 9:47 ` Nick Clifton 2005-03-01 16:38 ` Brett Porter 2005-03-01 17:27 ` Eric Christopher 2005-02-24 13:58 ` Changing .dynstr to be more C++ friendly? Alan Modra 2005-02-24 17:14 ` Chris Kirby 2005-02-24 17:28 ` Daniel Jacobowitz
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).