[LLVMdev] symbols for exception handling

Reed Kotler rkotler at mips.com
Sat Nov 3 17:21:58 PDT 2012

My patch seems to work. I'm passing all the mips16 exception handling 
tests from test-suite.

Unfortunately I touched a lot of target independent code so I'll have to 
get this patch reviewed. I will test with all Mips flavors and try with 
the x86 compiler this weekend.

I basically just created an EmitDebugLabel method in MCStreamer and all 
derived classes.

I added a new field to McAsmino for debug label suffix and made it ":" 
by default but for Mips I override it to be "=.".

In the dwarf emitter, you can EmitDebugLabel in place of EmitLabel.
For non mips targets, the two functions are the same.

I only call it right now for eh_func_beginXX right now because that is 
all you need to "right" for exception handling. I may have to go through 
the rest of the dwarf emitter and add more to get all the dwarf to work 
for mips16.

In principle, on the landing pad addresses in the table should be real 
mips16 isa addresses and the rest should be debug labels. That is how 
gcc mips16 does it.

On 11/03/2012 03:31 PM, Reed Kotler wrote:
> 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

More information about the llvm-dev mailing list