mips16 has some unusual requirements for label symbols in .s. I think that arm thumb has the same issue but have not located yet how this is handled. When you have a label of an instruction in mips16, when you reference the label, the linker adds a 1 to the address. When you call an odd numbered address, the procesor switches to mips16 mode and when you call an even numbered address it switches to mips32 mode. This causes some problems in the exception tables. Basically, labels that are not landing pad symbols that are inserted for exception handling and dwarf purposes, must declared : $mysym = . as opposed to: $mysym: Has this problem of making this distinction already been solved in llvm and if so, how is this done? Tia. Reed
I'm working on a patch for this problem for mips16; unfortunately it's a target independent patch. I'm not sure the best nomenclature for this. In the gcc mips16 patch they call "xxx=." a debug label. The other terminology they use is byte pointer vs ISA-encoded address (ISA-encoded meaning this one bit in the case of mips16 ISA). I'm planning to add a virtual method called EmitDebugLabel to MCStreamer which just calls method EmitLabel. Because of some luck, for exception handling at least, I really only need to EmitDebugLabel for eh_func_beginXX. The other entries in the exception table are all a-b, except for eh_func_beginXX, the 1 bits will cancel each other out. I don't know if this is sufficient for actual dwarf info for debugging; i have not thought through this yet. The real solution that gcc uses is to distinguish these two kinds of labels everywhere. On 11/02/2012 07:53 PM, reed kotler wrote:> mips16 has some unusual requirements for label symbols in .s. > > I think that arm thumb has the same issue but have not located yet how > this is handled. > > When you have a label of an instruction in mips16, when you reference > the label, the linker > adds a 1 to the address. When you call an odd numbered address, the > procesor switches to mips16 mode and when you call an even numbered > address it switches to mips32 mode. > > This causes some problems in the exception tables. > > Basically, labels that are not landing pad symbols that are inserted for > exception handling > and dwarf purposes, must declared : > > $mysym = . > > as opposed to: > > $mysym: > > Has this problem of making this distinction already been solved in llvm > and if so, how is this done? > > Tia. > > Reed
I thought of a simpler way to do this which is no more of a hack than the way labels are noramally output. Create an EmitDebugLabel and then in MCAsminfo, add another variable for the suffix for debug labels which can by default be just ":". Then for Mips I can change it to "=." On 11/03/2012 01:40 PM, Reed Kotler wrote:> I'm working on a patch for this problem for mips16; unfortunately it's a > target independent patch. > > I'm not sure the best nomenclature for this. > > In the gcc mips16 patch they call "xxx=." a debug label. > The other terminology they use is byte pointer vs ISA-encoded address > (ISA-encoded meaning this one bit in the case of mips16 ISA). > > I'm planning to add a virtual method called EmitDebugLabel to MCStreamer > which just calls method EmitLabel. > > Because of some luck, for exception handling at least, I really only > need to EmitDebugLabel for eh_func_beginXX. > > The other entries in the exception table are all a-b, except for > eh_func_beginXX, the 1 bits will cancel each other out. I don't know if > this is sufficient for actual dwarf info for debugging; i have not > thought through this yet. > > The real solution that gcc uses is to distinguish these two kinds of > labels everywhere. > > On 11/02/2012 07:53 PM, reed kotler wrote: >> mips16 has some unusual requirements for label symbols in .s. >> >> I think that arm thumb has the same issue but have not located yet how >> this is handled. >> >> When you have a label of an instruction in mips16, when you reference >> the label, the linker >> adds a 1 to the address. When you call an odd numbered address, the >> procesor switches to mips16 mode and when you call an even numbered >> address it switches to mips32 mode. >> >> This causes some problems in the exception tables. >> >> Basically, labels that are not landing pad symbols that are inserted for >> exception handling >> and dwarf purposes, must declared : >> >> $mysym = . >> >> as opposed to: >> >> $mysym: >> >> Has this problem of making this distinction already been solved in llvm >> and if so, how is this done? >> >> Tia. >> >> Reed
On Fri, Nov 02, 2012 at 07:53:41PM -0700, reed kotler wrote:> Basically, labels that are not landing pad symbols that are inserted > for exception handling > and dwarf purposes, must declared : > > $mysym = . > > as opposed to: > > $mysym:Can't you use $mysym +/- 1 in the landing pad reference to work this idiosyncracy? Joerg
Hi Joerg, Interesting idea.The landing pad reference is correct but all the other ones are off by one but the same idea applies. For the exception handling table I get lucky because all the label addresses that are off by one, except for eh_func begin, end up being subtracted from one another and the extra '1' cancels out. However, I'm not sure what the ramifications are in the dwarf tables. I'm just going by the original email discussions on this mips16 c++ handling from gcc that I found. This whole topic was discussed at length. If I follow the abi convention established there, then everything else will work.. gdb, exception library, etc. http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00623.html http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01273.html In any case, I need to make changes to mcstreamer and that is a class that is dervied from in several places. I can't put "if inMips16()" in mcstreamer. How would you suggest I handle the data abstraction so that I can change mcstreamer for my use and minimally effect others without polluting the namespace of mcstreamer with "mips16"? I have a patch I will submit today for review, though I'm not at all wedded to this idea, it's just something that is not unreasonable and I was able to get to work and solve my problem in a few hours. I just had to introduce the notion of EmitDebugSymbol to mcstreamer. Everything was very clean; the only issues was having to add EmitDDebugLabel as a synonym for EmitLabel in all the derived classes except for the assembler emitter, though I will need to make fixes later to at least the elf emitter to accommodate the direct object emitter. That part about having to touch those other derived classes seemed wrong to me but I didn't think of a better solution. reed On 11/04/2012 02:16 AM, Joerg Sonnenberger wrote:> On Fri, Nov 02, 2012 at 07:53:41PM -0700, reed kotler wrote: >> Basically, labels that are not landing pad symbols that are inserted >> for exception handling >> and dwarf purposes, must declared : >> >> $mysym = . >> >> as opposed to: >> >> $mysym: > > Can't you use $mysym +/- 1 in the landing pad reference to work this > idiosyncracy? > > Joerg >