[LLVMdev] symbols for exception handling
rkotler at mips.com
Sat Nov 3 15:31:18 PDT 2012
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:
>> Has this problem of making this distinction already been solved in llvm
>> and if so, how is this done?
More information about the llvm-dev