* Re: Unique section ids @ 2000-07-06 11:27 Nick Clifton 2000-07-08 5:16 ` Alan Modra 0 siblings, 1 reply; 6+ messages in thread From: Nick Clifton @ 2000-07-06 11:27 UTC (permalink / raw) To: law; +Cc: alan, binutils Hi Guys, : > Why can't you append the section name and input file name ? That way : > the (extended) local names would stay the same even if the link order : > is changed on the command line, something that would not happen with : > your unique section id scheme... : : You'll need full paths, not just the input file name -- ie, it is possible : to have "foobar.o" appear multiple times like : : gcc -o blah foobar.o frob/foobar.o : : Which brings up questions like what are valid characters -- filenames could : have embedded spaces, control chars, etc etc. Bah humbug! You are right though. The scheme would also fail to produce comparable binaries if the build tree were moved to a different location. : I mildly prefer the sequence #s approach. But I can live with either. Sequence IDs seem to be the simpler solution overall, so lets go with that. Alan - I assume that you will submit a full blown patch ? Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unique section ids 2000-07-06 11:27 Unique section ids Nick Clifton @ 2000-07-08 5:16 ` Alan Modra 0 siblings, 0 replies; 6+ messages in thread From: Alan Modra @ 2000-07-08 5:16 UTC (permalink / raw) To: Nick Clifton; +Cc: law, binutils On Thu, 6 Jul 2000, Nick Clifton wrote: > Sequence IDs seem to be the simpler solution overall, so lets go with > that. Alan - I assume that you will submit a full blown patch ? Yeah, I'd better make it clear in future when I'm posting something half-baked for discussion :-) This additional hunk is needed for initialisation of the four default sections. @@ -551,8 +552,8 @@ static const asymbol global_syms[] = #define STD_SECTION(SEC, FLAGS, SYM, NAME, IDX) \ const asymbol * const SYM = (asymbol *) &global_syms[IDX]; \ const asection SEC = \ - /* name, index, next, flags, set_vma, reloc_done, linker_mark, gc_mark */ \ - { NAME, 0, NULL, FLAGS, 0, 0, 0, 0, \ + /* name, id, index, next, flags, set_vma, reloc_done, linker_mark, gc_mark */ \ + { NAME, -1-(IDX), 0, NULL, FLAGS, 0, 0, 0, 0, \ \ /* vma, lma, _cooked_size, _raw_size, output_offset, output_section, */ \ 0, 0, 0, 0, 0, (struct sec *) &SEC, \ except that the patch I actually checked in reformatted this macro (and quite a few other things too, since we seem to be in tidy-up mode). I won't bother posting the full patch to the list as it's mainly white-space changes. The substantive changes are the above hunk with the patch I previously posted, and the patch to bfd/doc/chew.c below. bfd/ChangeLog * section.c (struct sec): Add id field. Tidy comment formatting. (bfd_make_section_anyway): Set id. (STD_SECTION): Init id too. Change CONST to const throughout. * archures.c (bfd_arch_info): Tidy comment. (bfd_arch_list): Change a CONST to const. * libbfd-in.h: Tidy comments and replace CONST with const. * elf-bfd.h: Likewise. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate. * libcoff.h: Regenerate. This one fixes a long-standing problem with "make headers" that messed up comments in bfd-in2.h and other generated files. bfd/doc/ChangeLog * chew.c (outputdots): Don't add a space before `/*'. (courierize): Likewise. Regards, Alan Modra -- Linuxcare. Support for the Revolution. Index: bfd/doc/chew.c =================================================================== RCS file: /cvs/src/src/bfd/doc/chew.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 chew.c --- chew.c 1999/05/03 07:28:58 1.1.1.1 +++ chew.c 2000/07/08 03:29:18 @@ -1,5 +1,5 @@ /* chew - Copyright (C) 1990, 91, 92, 93, 94, 95, 96, 1998 + Copyright (C) 1990, 91, 92, 93, 94, 95, 96, 1998, 2000 Free Software Foundation, Inc. Contributed by steve chamberlain @cygnus @@ -634,7 +634,7 @@ DEFUN_VOID(outputdots) { if (c == '{' && at(tos,idx+1) =='*') { - cattext(&out," /*"); + cattext(&out,"/*"); idx+=2; } else if (c == '*' && at(tos,idx+1) =='}') @@ -685,7 +685,7 @@ WORD(courierize) { if (at(tos,idx)=='{' && at(tos,idx+1) =='*') { - cattext(&out," /*"); + cattext(&out,"/*"); idx+=2; } else if (at(tos,idx)=='*' && at(tos,idx+1) =='}') ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unique section ids @ 2000-07-06 10:29 Nick Clifton 2000-07-06 10:58 ` Jeffrey A Law 0 siblings, 1 reply; 6+ messages in thread From: Nick Clifton @ 2000-07-06 10:29 UTC (permalink / raw) To: alan; +Cc: binutils Hi Alan, : I'd like to add another field to the asection structure to uniquely : identify input sections. The reason for this is that the hppa port needs : to create long branch stubs to local symbols, and some means is needed to : make local symbols globally unique so we can use a hash lookup. I'm : currently using the following: : : if (h == NULL) : sprintf (stub_name + len - 10, "_%08x", : (int) sym_sec & 0xffffffff); : : ie. We just tack on the address of the asection structure. This works : quite well, but it has the drawback that the memory address of the : structure is fairly random. For exactly the same input files, stubs : output via bfd_hash_traverse come in a different order for different : linker builds. This makes comparison of output files (and debugging the : linker) more difficult. : : Has anyone a better idea? Or can point me to an existing way of uniquely : identifying input sections short of enumerating over input bfds? Why can't you append the section name and input file name ? That way the (extended) local names would stay the same even if the link order is changed on the command line, something that would not happen with your unique section id scheme... Mind you I have no real objections to your suggestion, if that is how you want to proceed. I would suggest renaming the new field to 'unique_id' just to make its purpose clear. Cheers Nick ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unique section ids 2000-07-06 10:29 Nick Clifton @ 2000-07-06 10:58 ` Jeffrey A Law 0 siblings, 0 replies; 6+ messages in thread From: Jeffrey A Law @ 2000-07-06 10:58 UTC (permalink / raw) To: Nick Clifton; +Cc: alan, binutils In message < 200007061729.KAA32533@elmo.cygnus.com >you write: > Why can't you append the section name and input file name ? That way > the (extended) local names would stay the same even if the link order > is changed on the command line, something that would not happen with > your unique section id scheme... You'll need full paths, not just the input file name -- ie, it is possible to have "foobar.o" appear multiple times like gcc -o blah foobar.o frob/foobar.o Which brings up questions like what are valid characters -- filenames could have embedded spaces, control chars, etc etc. I mildly prefer the sequence #s approach. But I can live with either. jeff ^ permalink raw reply [flat|nested] 6+ messages in thread
* Unique section ids @ 2000-07-05 21:00 Alan Modra 2000-07-06 10:09 ` Jeffrey A Law 0 siblings, 1 reply; 6+ messages in thread From: Alan Modra @ 2000-07-05 21:00 UTC (permalink / raw) To: binutils I'd like to add another field to the asection structure to uniquely identify input sections. The reason for this is that the hppa port needs to create long branch stubs to local symbols, and some means is needed to make local symbols globally unique so we can use a hash lookup. I'm currently using the following: if (h == NULL) sprintf (stub_name + len - 10, "_%08x", (int) sym_sec & 0xffffffff); ie. We just tack on the address of the asection structure. This works quite well, but it has the drawback that the memory address of the structure is fairly random. For exactly the same input files, stubs output via bfd_hash_traverse come in a different order for different linker builds. This makes comparison of output files (and debugging the linker) more difficult. Has anyone a better idea? Or can point me to an existing way of uniquely identifying input sections short of enumerating over input bfds? Regards, Alan Modra -- Linuxcare. Support for the Revolution. --- section.c~ Fri Apr 7 10:54:53 2000 +++ section.c Thu Jul 6 12:58:25 2000 @@ -178,6 +178,10 @@ CODE_FRAGMENT . . CONST char *name; . +. {* A unique sequence number. *} +. +. int id; +. . {* Which section is it; 0..nth. *} . . int index; @@ -683,6 +687,7 @@ bfd_make_section_anyway (abfd, name) bfd *abfd; CONST char *name; { + static int section_id = 0; asection *newsect; asection **prev = &abfd->sections; asection *sect = abfd->sections; @@ -704,6 +709,7 @@ bfd_make_section_anyway (abfd, name) return NULL; newsect->name = name; + newsect->id = section_id++; newsect->index = abfd->section_count++; newsect->flags = SEC_NO_FLAGS; ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Unique section ids 2000-07-05 21:00 Alan Modra @ 2000-07-06 10:09 ` Jeffrey A Law 0 siblings, 0 replies; 6+ messages in thread From: Jeffrey A Law @ 2000-07-06 10:09 UTC (permalink / raw) To: Alan Modra; +Cc: binutils In message < Pine.LNX.4.21.0007061317050.353-100000@front.linuxcare.com.au >you write: > I'd like to add another field to the asection structure to uniquely > identify input sections. The reason for this is that the hppa port needs > to create long branch stubs to local symbols, and some means is needed to > make local symbols globally unique so we can use a hash lookup. I'm > currently using the following: > > if (h == NULL) > sprintf (stub_name + len - 10, "_%08x", > (int) sym_sec & 0xffffffff); > > ie. We just tack on the address of the asection structure. This works > quite well, but it has the drawback that the memory address of the > structure is fairly random. For exactly the same input files, stubs > output via bfd_hash_traverse come in a different order for different > linker builds. This makes comparison of output files (and debugging the > linker) more difficult. > > Has anyone a better idea? Or can point me to an existing way of uniquely > identifying input sections short of enumerating over input bfds? Sounds like a good idea to me. I've never been proud of that terrible code fragment, just about anything would be cleaner. jeff ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-07-08 5:16 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-07-06 11:27 Unique section ids Nick Clifton 2000-07-08 5:16 ` Alan Modra -- strict thread matches above, loose matches on Subject: below -- 2000-07-06 10:29 Nick Clifton 2000-07-06 10:58 ` Jeffrey A Law 2000-07-05 21:00 Alan Modra 2000-07-06 10:09 ` Jeffrey A Law
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).