On 12/02/2014 05:54 PM, Daniel Sanders wrote:
I could be completely off-track here, but my initial attempts at using 
abi-compliance-checker on a subset of the public headers (everything in 
$prefix/include/llvm/Target, and 
$prefix/include/llvm/ExecutionEngine/ExecutionEngine.h) haven't reported 
anything other than --prefix related differences and this got me thinking.

We only need to worry about symbols that the user can directly access from the 
definitions in the public (installed) headers and not the whole symbol table, 
don't we? These symbols are in the symbol table for the shared library, but as 
far as I can tell there is no definition in the public headers that could 
enable a user to directly reference anything from $srcdir/lib/Target/Mips (not 
even the create* functions).


This is a good point, and I think you are right about this.  I have been
using the ABI checker with -objects-only so it wasn't considering the
headers at all.  I think we are probably OK then with these deleted symbols
for now, thanks for looking into this and sorry you had to be the guinea pig.

I will try to get the ABI checker to consider the headers too.  I had some
trouble with this last time, but maybe a newer gcc will help.

-Tom

________________________________________
From: Daniel Sanders
Sent: 02 December 2014 17:02
To: Tom Stellard; Stellard, Thomas; [email protected]
Subject: RE: Deleted Mips symbols in the 3.5 branch

________________________________________
From: Tom Stellard [[email protected]]
Sent: 02 December 2014 16:49
To: Daniel Sanders; Stellard, Thomas; [email protected]
Subject: Re: Deleted Mips symbols in the 3.5 branch

On 12/02/2014 11:46 AM, Daniel Sanders wrote:
From: Tom Stellard [[email protected]]
Sent: 02 December 2014 16:27
To: Daniel Sanders; Stellard, Thomas; [email protected]
Subject: Re: Deleted Mips symbols in the 3.5 branch

On 12/02/2014 11:25 AM, Daniel Sanders wrote:
I've re-added these functions in my working copy but it's had no effect on the 
symbol table for libLLVM-3.5.so.
It looks like the compiler (or perhaps the linker?) is deleting them because 
they are unused private members of
the MipsTargetLowering and MipsCC classes.


I think they need to be public members to show up in the symbol table.
Were they public before?

-Tom

On double-checking, I did have a small mistake here but fixing it hasn't helped.

The member functions of MipsTargetLowering were private before the patch 
series. MipsCC was a protected class inside MipsTargetLowering. The member 
functions of MipsCC were public.

After matching this, the symbol table is still unchanged between the a clean 
checkout of the release_35 branch and my current working copy that tries to 
bring these symbols back.


Ok, can you send me these patches.

-Tom


Sure, attached.

-----Original Message-----
From: Stellard, Thomas [mailto:[email protected]]
Sent: 02 December 2014 00:25
To: Daniel Sanders; [email protected]
Subject: RE: Deleted Mips symbols in the 3.5 branch

I don't think it maters whether the function bodies are empty, or if they have
llvm_unreachable().  Though, I think it would be easier to use
llvm_unreachable(), since you wouldn't have to worry about the return type.



-Tom
________________________________________
From: Daniel Sanders [[email protected]]
Sent: Monday, December 01, 2014 6:39 PM
To: Stellard, Thomas; [email protected]
Subject: RE: Deleted Mips symbols in the 3.5 branch

Hi,

Thanks for the list. Most of these seem to be related to the MipsCC class
which was removed during the refactoring portions of the patch series. IIRC,
MipsCC was only used for a local in a few functions such as
LowerFormalArguments() so it probably shouldn't have been public in the
first place, but I'll re-add them in the morning anyway. Just to double check,
when you say 'add them back as no-ops' do you mean with empty function
bodies, or with llvm_unreachable() inside them?

________________________________________
From: Tom Stellard [[email protected]]
Sent: 01 December 2014 16:33
To: Daniel Sanders; [email protected]
Subject: Deleted Mips symbols in the 3.5 branch

Hi Daniel,

r223008 to r223037 have deleted some public symbols, which will need to be
added back to maintain ABI compatibility. I'm not sure, but I think some of
these may be generated by TableGen.

If these functions are no longer used, you can add them back as no-ops if
that is easier.  Sorry I overlooked this during my review.  Here are the
deleted symbols:

_ZN4llvm18MipsTargetLowering6MipsCC12allocateRegsERNS0_12ByValArgIn
foEjj
_ZNK4llvm18MipsTargetLowering6MipsCC10fixedArgFnEv
_ZN4llvm18MipsTargetLowering6MipsCC14handleByValArgEjNS_3MVTES2_
NS_11CCValAssign7LocInfoENS_3ISD10ArgFlagsTyE
_ZNK4llvm18MipsTargetLowering6MipsCC10shadowRegsEv

_ZNK4llvm18MipsTargetLowering12passByValArgENS_7SDValueENS_5SDLoc
ERSt5dequeISt4pairIjS1_ESaIS5_EERNS_15SmallVectorImplIS1_EES1_PNS_16
MachineFrameInfoERNS_12SelectionDAGES1_RKNS0_6MipsCCERKNS0_12By
ValArgInfoERKNS_3ISD10ArgFlagsTyEb
_ZNK4llvm18MipsTargetLowering6MipsCC13analyzeReturnERKNS_15SmallVe
ctorImplINS_3ISD9OutputArgEEEbPKNS_4TypeE
_ZNK4llvm18MipsTargetLowering6MipsCC8varArgFnEv

_ZNK4llvm18MipsTargetLowering15LowerCallResultENS_7SDValueES1_NS_1
1CallingConv2IDEbRKNS_15SmallVectorImplINS_3ISD8InputArgEEENS_5SDLo
cERNS_12SelectionDAGERNS4_IS1_EEPKNS_6SDNodeEPKNS_4TypeE

_ZN4llvm18MipsTargetLowering6MipsCC19analyzeCallOperandsERKNS_15S
mallVectorImplINS_3ISD9OutputArgEEEbbPKNS_6SDNodeERSt6vectorINS_1
4TargetLowering12ArgListEntryESaISD_EE

_ZN4llvm18MipsTargetLowering6MipsCC22analyzeFormalArgumentsERKNS_
15SmallVectorImplINS_3ISD8InputArgEEEbNS_14ilist_iteratorIKNS_8Argume
ntEEE

_ZNK4llvm20MipsSETargetLowering33isEligibleForTailCallOptimizationERKNS_
18MipsTargetLowering6MipsCCEjRKNS_16MipsFunctionInfoE
_ZN4llvm18MipsTargetLowering6MipsCCC2ENS_11CallingConv2IDEbbRNS_7
CCStateENS1_22SpecialCallingConvTypeE
_ZNK4llvm18MipsTargetLowering6MipsCC13numIntArgRegsEv

_ZNK4llvm18MipsTargetLowering15writeVarArgRegsERSt6vectorINS_7SDVal
ueESaIS2_EERKNS0_6MipsCCES2_NS_5SDLocERNS_12SelectionDAGE
_ZNK4llvm18MipsTargetLowering21getSpecialCallingConvENS_7SDValueE

_ZNK4llvm18MipsTargetLowering13copyByValRegsENS_7SDValueENS_5SDLo
cERSt6vectorIS1_SaIS1_EERNS_12SelectionDAGERKNS_3ISD10ArgFlagsTyERN
S_15SmallVectorImplIS1_EEPKNS_8ArgumentERKNS0_6MipsCCERKNS0_12B
yValArgInfoE
_ZNK4llvm18MipsTargetLowering6MipsCC17analyzeCallResultERKNS_15Small
VectorImplINS_3ISD8InputArgEEEbPKNS_6SDNodeEPKNS_4TypeE

_ZNK4llvm20Mips16TargetLowering33isEligibleForTailCallOptimizationERKNS_
18MipsTargetLowering6MipsCCEjRKNS_16MipsFunctionInfoE
_ZN4llvm18MipsTargetLowering6MipsCCC1ENS_11CallingConv2IDEbbRNS_7
CCStateENS1_22SpecialCallingConvTypeE

-Tom



_______________________________________________
llvm-branch-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-branch-commits

Reply via email to