https://sourceware.org/bugzilla/show_bug.cgi?id=33186
--- Comment #4 from Indu Bhagat <indu.bhagat at oracle dot com> --- (In reply to Pavel Labath from comment #3) > (In reply to Indu Bhagat from comment #2) > > Right, most users will only ever see (and need) SFrame sections with name > > ".sframe". > > That's true, but you could also say that (in the future, when everything > generates SHT_GNU_SFRAME), most users will only see SFrame sections with > SHT_GNU_SFRAME. > > > > > So then, taking a step back though, I am curious if you have some specific > > usecase on hand, where SFrame sections with a name distinct from .sframe is > > created or multiple SFrame sections are generated per object. > > > > For ET_DYN, ET_EXEC, there should be only one SFrame section with sorted > > FDEs for it to be useful for fast stacktracing. For ET_REL too, I dont see > > why multiple SFrame sections will be needed. Is that complexity necessary ? > > No, I don't have an real use case in mind -- I'm just thinking about the > edge cases. We now sort of have two ways to identify an sframe section (via > its name and via the section type), so I'm wondering which one should we > trust more. So like, imagine we had an object file with two sections: one > called ".sframe" but with a random type; and another, whose type was > SHT_GNU_SFRAME, but it was *not* called ".sframe". Which of these two should > be considered the real SFrame section? > Now that we SHT_GNU_SFRAME, trusting the section type makes sense. Unfortunately, for GNU Binutils, some allowance needs to be made so that SFrame sections generated with Binutils <= 2.44 (SHT_PROGBITS, name .sframe) can still be dumped when possible. -- You are receiving this mail because: You are on the CC list for the bug.
