Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-04-03T14:53:42+00:00 2019-04-03T14:53:42+00:00 George Rimar grimar@accesssoftek.com 2019-04-03T14:53:42+00:00 urn:sha1:6da44ad75d25d5d7089c66d7cd3f4f90cd70146c Currently, YAML has the following syntax for describing the symbols: Symbols: Local: LocalSymbol1: ... LocalSymbol2: ... ... Global: GlobalSymbol1: ... Weak: ... GNUUnique: I.e. symbols are grouped by their bindings. That is not very convenient, because: It does not allow to set a custom binding, what can be useful for producing broken/special outputs for test cases. Adding a new binding would require to change a syntax (what we observed when added GNUUnique recently). It does not allow to change the order of the symbols in .symtab/.dynsym, i.e. currently all Local symbols are placed first, then Global, Weak and GNUUnique are following, but we are not able to change the order. It is not consistent. Binding is just one of the properties of the symbol, we do not group them by other properties. It makes the code more complex that it can be. This patch shows it can be simplified with the change performed. The patch changes the syntax to just: Symbols: Symbol1: ... Symbol2: ... ... With that, we are able to work with the binding field just like with any other symbol property. Differential revision: https://reviews.llvm.org/D60122 llvm-svn: 357595 2019-03-12T17:00:25+00:00 James Henderson jh7370@my.bristol.ac.uk 2019-03-12T17:00:25+00:00 urn:sha1:9bc817a0ae7d629417e369c0612b6312b7437dfa Prior to this change, the "Symbol" field of a relocation would always be assumed to be a symbol name, and if no such symbol existed, the relocation would reference index 0. This confused me when I tried to use a literal symbol index in the field: since "0x1" was not a known symbol name, the symbol index was set as 0. This change falls back to treating unknown symbol names as integers, and emits an error if the name is not found and the string is not an integer. Note that the Symbol field is optional, so if a relocation doesn't reference a symbol, it shouldn't be specified. The new error required a number of test updates. Reviewed by: grimar, ruiu Differential Revision: https://reviews.llvm.org/D58510 llvm-svn: 355938 2016-06-27T19:53:53+00:00 Chris Bieneman beanz@apple.com 2016-06-27T19:53:53+00:00 urn:sha1:8ff0c113575167809365d2de5f6a204ff9c9c2bb Summary: Our YAML library's handling of tags isn't perfect, but it is good enough to get rid of the need for the --format argument to yaml2obj. This patch does exactly that. Instead of requiring --format, it infers the format based on the tags found in the object file. The supported tags are: !ELF !COFF !mach-o !fat-mach-o I have a corresponding patch that is quite large that fixes up all the in-tree test cases. Reviewers: rafael, Bigcheese, compnerd, silvas Subscribers: compnerd, llvm-commits Differential Revision: http://reviews.llvm.org/D21711 llvm-svn: 273915 2016-03-28T13:09:54+00:00 Jacques Pienaar jpienaar@google.com 2016-03-28T13:09:54+00:00 urn:sha1:fcef3e46172bdb8ef0d9e9d08bdd9bf886c16d3d Add the Lanai backend to lib/Target. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17011 llvm-svn: 264578 2016-03-01T21:21:42+00:00 Jacques Pienaar jpienaar@google.com 2016-03-01T21:21:42+00:00 urn:sha1:ea9f25a740f36305e2265903c5277770d6e977cd Add ELF enum value and relocations for Lanai backed. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17008 llvm-svn: 262394