search for: functionpadmin

On 10/26/10 5:24 PM, Michael Spencer wrote: > The linker adds the padding. Also, the first instruction just has to > be two bytes or longer. Not exactly two bytes. How then does the linker know to add the padding? I assume there's a PE-COFF attribute that will do that, but what about other file formats, like ELF or Mach-O? Bear in mind that I'm doing this for the Wine project, so

...s the padding. Also, the first instruction just has to >> be two bytes or longer. Not exactly two bytes. > How then does the linker know to add the padding? I assume there's a > PE-COFF attribute that will do that, Nope, that information is not in the object file. You have to pass /FUNCTIONPADMIN to the linker which then figures it out. > but what about other file formats, > like ELF or Mach-O? Bear in mind that I'm doing this for the Wine > project, so I'm very concerned about those two formats. > > Chip There is no standard hotpatch ABI/toolchain for those object...

...2 /MD In this list the only weird one is /bigobj, my main fear is that we might get to the limit of sections on an obj and then by adding the .debug$H with llvm-objcopy we might get over the limit (I didn't see any code on the obj coff writer to deal with that). For the linker I was using: /FUNCTIONPADMIN:6 /MACHINE:X64 /DEBUG:GHASH -time /INCREMENTAL:NO But I'm going to be adding: /OPT:NOREF /OPT:NOICF because maybe the wrong callstacks might be related to ICF. I will try to get a simple test case to show this erros, but its difficult, debugging mostly works, its just on some complicated case...

Hi, We are starting to test binaries generated by lld on windows and we notices that sometimes the visual studio debugger can't see the content of variables or gets the call stack wrong for deeply nested or complex types. Did anyone else have the same problems, or any way to try to figure out what is missing? I tried llvm-pdbutil dump -symbols but there is a lot of small diferences on