[llvm-branch-commits] Deleted Mips symbols in the 3.5 branch

[Daniel Sanders]

> -----Original Message-----
> From: Tom Stellard [mailto:thomas.stellard at amd.com]
> Sent: 03 December 2014 16:25
> To: Daniel Sanders; Stellard, Thomas; llvm-branch-commits at cs.uiuc.edu
> Subject: Re: Deleted Mips symbols in the 3.5 branch
> 
> On 12/03/2014 05:11 AM, Daniel Sanders wrote:
> >> -----Original Message-----
> >> From: Tom Stellard [mailto:thomas.stellard at amd.com]
> >> Sent: 03 December 2014 02:16
> >> To: Daniel Sanders; Stellard, Thomas; llvm-branch-commits at cs.uiuc.edu
> >> Subject: Re: Deleted Mips symbols in the 3.5 branch
> >>
> >> 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.
> >>
> >
> > No problem. I need to learn quite a lot of the implementation detail for C++
> anyway and this has been very helpful for that.
> >
> 
> Hi Daniel,
> 
> It took one hour and 8 GBs of memory, but I got the ABI checker working
> with headers.
> It looks like there is one patch that breaks the ABI: r223018  In
> include/llvm/CodeGen/CallingConvLower, this commits adds new members
> to the middle of
> enum LocInfo, which changes the values of some existing members.  The
> new members should
> be added to the end.  Would you be able to fix this?
> 
> Thanks,
> Tom

Fixed in r223242.