<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Third times the charm. This time with the patches attached<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF644611"><font face="Tahoma" color="#000000" size="2"><b>From:</b> Carter, Jack<br>
<b>Sent:</b> Wednesday, February 13, 2013 1:06 PM<br>
<b>To:</b> llvm-commits@cs.uiuc.edu<br>
<b>Cc:</b> grosbach@apple.com; echristo@gmail.com<br>
<b>Subject:</b> [PATCH] review request [MC ELF] symbol table STO support<br>
</font><br>
</div>
<div></div>
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">This time with my old email address:<br>
ELF symbol table field st_other support, <br>
excluding visibility bits.<br>
<br>
Attached are 2 patches: generic STO handling<br>
and Mips specific STO setting with a test case.<br>
<br>
The st_other field of the ELF symbol table is one<br>
byte in size. The first 2 bytes are used for generic<br>
visibility and are currently handled by llvm.<br>
<br>
The other six bits are processor specific and need <br>
to be set at the target level.<br>
<br>
A couple of notes:<br>
<br>
The Mips specific enumerations in ELF.h are not strictly<br>
in value order. The mask value for a group of values is<br>
placed before the flag values it will mask.<br>
<br>
The new static methods for accessing and setting the "other"<br>
flags in include/llvm/MC/MCELF.h match the style guide<br>
and not the other methods in the file. I don't like the<br>
inconsistency, but feel I should follow the prescribed <br>
lowerUpper() convention.<br>
<br>
STO_ value definitions are not specified in gnu land as <br>
consistently as the STT_ and STB_ fields. Probably because<br>
the latter were defined in a standards doc and the former<br>
defined partially in code. I have stuck with the full byte<br>
definition of the flags.<br>
<br>
This has gone through internal review. Let me know if I<br>
may check it in.<br>
<br>
Contributer: Zoran Jovanovic<br>
<br>
</div>
</div>
</div>
</div>
</body>
</html>