Re: stabs changes for 64 bit targets
Jakub Jelinek wrote: > On Mon, May 13, 2013 at 10:45:46AM -0400, David Taylor wrote: > > There are problems when using current STABS debug format for 64 bit > > targets. > > Why are you considering extending STABS at this point? > STABS support might very well be dropped altogether from GCC 4.9 or the next > release, people just should use DWARF[234] everywhere. There are multiple reasons. One of the big reasons is... Prior to GCC 4.7, DWARF is too verbose compared to STABS. In STABS, all strings go into the string table; identical strings get put into the table just once. In DWARF, prior to GCC 4.7, macro strings do not go into the string table. If 1000 files all include a given header file, each #define in that header gets its own string in the debug information -- so the string is present 1000 times. GCC 4.7 (DWARF4) fixes this. We have STABS extensions (posted years ago, but never merged) that record macros in the STABS debug information -- at the -g3 level, just like for DWARF. [Posting updated MACRO extensions and trying to get them merged in is on my plate as part of the internal upgrade from gdb 7.1 to gdb 7.6. The extensions predate 7.1.] We are currently using GCC 4.5.4 for most things; 4.6.x for others. I don't knbow the details, but 4.7 was (is?) considered unacceptable, so we're planning on skipping it and waiting for 4.8.1 or later. There are other reasons besides the DWARF verboseness, but they are solvable. The verboseness (over 10x increase in the size of the elf file) is a show stopper. So, for now, we're sticking with STABS. I would like the 16 bytes STABS to be done in a manner that they would be considered for inclusion.
Re: stabs changes for 64 bit targets
On Tue, May 14, 2013 at 10:38 AM, David Taylor wrote: > Jakub Jelinek wrote: > >> On Mon, May 13, 2013 at 10:45:46AM -0400, David Taylor wrote: >> > There are problems when using current STABS debug format for 64 bit >> > targets. >> >> Why are you considering extending STABS at this point? >> STABS support might very well be dropped altogether from GCC 4.9 or the next >> release, people just should use DWARF[234] everywhere. > > There are multiple reasons. One of the big reasons is... > > Prior to GCC 4.7, DWARF is too verbose compared to STABS. > > In STABS, all strings go into the string table; identical strings get > put into the table just once. > > In DWARF, prior to GCC 4.7, macro strings do not go into the string > table. If 1000 files all include a given header file, each #define in > that header gets its own string in the debug information -- so the > string is present 1000 times. GCC 4.7 (DWARF4) fixes this. > > We have STABS extensions (posted years ago, but never merged) that > record macros in the STABS debug information -- at the -g3 level, just > like for DWARF. Please keep in mind that AIX continues to use STABS with its XCOFF file format, so please do not make changes to STABS under the assumption that you are the only producer and consumer. AIX added support for DWARF and I believe that there are some patches to support DWARF on AIX from Adacore, but those have not been merged into FSF GCC, Binutils and GDB yet. Thanks, David
Re: GSoC openMP task scheduling Advice
Hi All, I applied gsoc for openMP taks scheduling and my advice may cover taskyield facility. Currently i have some idea for taskyield. i think i can add something. Therefore i wonder GCC mentor related about openMP was announced? or should i wait until "student acceptance"? Regards, Güray Özen Polytechnic University of Catalonia 2013/5/5 guray.ozen : > Dear Tobias, > > Thank for your interest. > > Yes actually my Master program managed by BSC. So generally my professors > work from BSC or Intel. I know BSC has a nanos group and the group works > generally task scheduling. But i don't know any people from this group. If i > get openmp task project, I'll meet them and i can request help. maybe they > have good trick to implement my advice. Or they may improve my advice. > > Finally I applied gsoc. I hope I'll be accepted :) my advice can cover > openmp3.1 taskyield facility beside task scheduling optimization. Of course > task scheduling contains task stealing. Is like to much i can work on gcc > for openmp. > > Regards, > > On May 3, 2013 1:08 AM, "Tobias Burnus" wrote: >> >> Dear Güray, >> >> seemingly, Jakub is currently rather busy - let me try to answer the >> questions, given that the GSoC dead line is tomorrow. >> >>> I'm MSc High-Performance Computing student at Polytechnic University >>> of Catalonia(BarcelonaTech). >> >> >> For curiosity, do you have something to do with the BSC? Or some other >> on-site person, who is knowledgeable in OpenMP scheduling. >> >> >> (I know that it is a separate entity, but it could be that you have still >> some relation with them - or one of your professors.) >> >>> However i am not sure for this topics. Should i develop a new >>> task-scheduler? otherwise should I optimize existing scheduler? >> >> >> I think it would be useful to try a different talk scheduler, especially >> with regards to task stealing. See http://www.cs.unc.edu/~olivier/ross11.pdf >> for a comparison. >> >> Something similar like the task scheduling of OpenUH's DEQUEUE PER_THREAD1 >> with a doubly linked chain would be useful to try. (That's alledgedly >> similar to the extension to the Qthreads multithreading library using the >> ROSE compiler, used in Olivier's paper.) >> >> I think having some implementation of that scheduling and comparing it >> with the current one would be useful - then one can decide whether the new >> one is better or the current one or whether both should be available for the >> user to switch between the two. >> >> In any case, it is useful to study the literature about the details - but >> then get quickly starting with the implementation to make it possible to >> really play with the scheduler in GCC. >> >> >> Am 01.05.2013 18:50, schrieb guray.ozen: >>> >>> My advice i want to change or add task scheduler algorithm. The first >>> thing I really want to add work-stealing mechanism. In this way i can >>> decrease task waiting time and i can provide load-balancing. >> >> >> Yes, that's in line with the idea above. I think one has to look at the >> literature at the algorithm - and then try to get it implemented. >> >> Regarding the GSoC application, it would be good to give some success >> criteria and time line - that helps later when implementing and also with >> the application. >> >> For some ideas how to write the application, see: >> http://drupal.org/node/59037, http://drupal.org/files/application.pdf, >> http://of-code.blogspot.de/2007/08/soc-experience-introduction.html >> >> It is not required to be extremely long, but it should cover what exactly >> you intent to do and how long the single steps will (roughly) take. >> >> Tobias
Re: stabs changes for 64 bit targets
On Tue, 14 May 2013 10:38:02 -0400, David Taylor wrote: > There are other reasons besides the DWARF verboseness, but they are > solvable. The verboseness (over 10x increase in the size of the elf > file) is a show stopper. People keep saying that here from time to time. You said it earlier this year, but despite trying quite hard I've never been able to reproduce such horrible reasons anywhere. I sent you some results of my tests, see http://gcc.gnu.org/ml/gcc/2013-01/msg00142.html and the whole discussion surrounding it, but you did not reply. I really don't think further changes to the stabs support should be made at this point, other than a full re-write to mimic the DWARF model of representing the debug info internally somehow and only emit it at the end. That would make it compatible again with PCH and LTO, and would *finally* make the front ends not dependent on asm target hooks/macros. It's even been suggested to internally represent everything as DWARF and to write a dwarf-to-stabs debug emitter. Ciao! Steven
Re: GSoC openMP task scheduling Advice
guray.ozen wrote:
I applied gsoc for openMP taks scheduling and my advice may cover
taskyield facility. Currently i have some idea for taskyield. i think
i can add something. Therefore i wonder GCC mentor related about
openMP was announced? or should i wait until "student acceptance"?
You have to wait until "Accepted student proposals announced on the
Google Summer of Code 2013 site." (May 27: 19:00 UTC). Only then it is
known whether a student will be accepted - and who will mentor him (or her).
Of course, you can also work on GCC outside of the GSoC project - and
discuss your addition on the GCC list. But in that case, no designated
mentor exists. ("Outside GSoC" includes contributions done before (or
after) the GSoC work period - or any work unrelated to GSoC-accepted
projects [for instance: if a project doesn't get accepted or
contributing (additionally) for a different org].)
Thus, feel free to share/discuss your ideas - but don't expect mentoring
prior the acceptance to GSoC; expect only the normal support any
(potential) contributor will get.
Tobias,
who works on GCC in his spare time
Re: stabs changes for 64 bit targets
Steven Bosscher wrote: > On Tue, 14 May 2013 10:38:02 -0400, David Taylor wrote: > > There are other reasons besides the DWARF verboseness, but they are > > solvable. The verboseness (over 10x increase in the size of the elf > > file) is a show stopper. > > People keep saying that here from time to time. You said it earlier > this year, but despite trying quite hard I've never been able to > reproduce such horrible reasons anywhere. I sent you some results of > my tests, see http://gcc.gnu.org/ml/gcc/2013-01/msg00142.html and the > whole discussion surrounding it, but you did not reply. I remember replying to several messages on the subject from various people. As I recall, the problem is largely gone in 4.7 -- it was an earlier version that had the big big problem. Prior to 4.7, DWARF at level 3 verboseness (i.e., turn on emitting macros), stores each macro separately rather than in a string table. Non macro strings are in a string table, but not macros. With STABS, at -g3 (store macros -- local extension, posted years ago, but never accepted / merged) all the strings go into the string table with each string appearing just once. I learned after the discussion had died out that the bulk of the increase was due to the macros. If I recall correctly, without macros the increase was more like 20-30%. I might be remembering the percentage wrong, but I do remember that DWARF was still bigger than STABS. Being able to expand macros in the debugger is important to some of our users, so I'm not willing to turn that off. Once 4.8.1 comes out I'm willing to revisit the question of possibly switching to DWARF and trying to convince by boss and his boss that we should switch. But, not now. > I really don't think further changes to the stabs support should be > made at this point, other than a full re-write to mimic the DWARF > model of representing the debug info internally somehow and only emit > it at the end. That would make it compatible again with PCH and LTO, > and would *finally* make the front ends not dependent on asm target > hooks/macros. It's even been suggested to internally represent > everything as DWARF and to write a dwarf-to-stabs debug emitter. > > Ciao! > Steven >From a format perspective, the 12 bytes -> 16 bytes change is fairly minor. When fetching / storing an entry, the meaning / interpretation of the entry is the same except for the size of the address field -- 4 bytes vs 8 bytes. I could argue that for the x86-64, for anything other than small memory model, STABS should have had 8 bytes for the address field all along. But, its been 4 bytes for years and I would like to maintain backwards compatibility... So, I think that the cleanest backwards compatible solution is to put the STABS with a bigger address field into a different section. I would be agreeable to using the same section name as currently and putting the information into the zeroth entry if we can achieve consensus on what it should be. On the other hand, if the consensus is that there should be no changes to STABS, then when we finish our changes I won't bother posting the changes.
