search for: debug64

...hink I have isolated the issue (to a certain extent) in the attached Test.cpp file. Basically, I think linking with boost serialization is causing the plugin to fail. If I compile Test.cpp with line 43 (Dummy* Read() ...) commented out, I get the expected output in R: > dyn.load("../MinGW/Debug64/Tester.dll",DLLpath="C:/Sys/boost/MinGW64/boost_1_50_0/lib") Hello World. > .Call("add",c(1,3)) [1] 4 > is.loaded("add") [1] TRUE However, if line 43 is uncommented, the output changes to > dyn.load("../MinGW/Debug64/Tester.dll",DLLpath="...

In https://groups.google.com/g/generic-abi/c/i2Xio-47QdQ (you need to join the group before making a post) Cary Coutant raised yet another idea: whether we can use ".debug64" as the section prefix. I like the idea because of: * It is immediately obvious whether DWARF64 is used and whether DWARF32 is used along with DWARF64. * In a relocatable link mixing DWARF32 and DWARF64 sections, DWARF32 and DWARF64 sections will naturally not get mixed. (For a relocation bas...

...finline -fno-inline-functions -fno-builtin -fno-asm+ /opt/SUNWspro/bin/cc -xarch=amd64 -Ui386 -U__i386 -xO3 -W2,-Rlazy ../../intel/opt/work/src/osox-src-2006-08-16/usr/src/tools/proto/opt/onbld/bin/i386/ctfcon ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -gRemoving debug64/hat.o *** Error code 1 dmake: Warning: Command failed for target `debug64/hat.o'' previously I downloaded required packages from http://opensolaris.org/os/community/xen/How-To-8-15-06/Downloads-Page-8-15-06 and ran: (though I am not sure everything here is a MUST): http://opensolaris.o...

I was thinking about whether I liked the section name idea myself. I think a slight refinement could be to have linkers combine .debug and .debug64 sections into one output section (in non -r links), so that end consumers (debuggers etc) don't have to worry about it. However, conformance is still a concern to me as we cannot really retrofit the existing standard versions, and the section names themselves are in the standard. That means tha...

.../uts/i86pc/io/intel_iommu.c usr/src/uts/i86xpv/xnb/Makefile usr/src/uts/intel/ia32/ml/modstubs.s usr/src/uts/intel/io/amd8111s/amd8111s_main.c usr/src/uts/intel/io/amd8111s/amd8111s_main.h usr/src/uts/intel/io/dktp/disk/cmdk.c usr/src/uts/intel/ip/Makefile usr/src/uts/intel/ip/ip.global-objs.debug64 usr/src/uts/intel/ip/ip.global-objs.obj64 usr/src/uts/intel/mac/Makefile usr/src/uts/intel/smbfs/Makefile usr/src/uts/intel/vnic/Makefile usr/src/uts/intel/xge/Makefile usr/src/uts/sparc/ip/Makefile usr/src/uts/sparc/ip/ip.global-objs.debug64 usr/src/uts/sparc/ip/ip.global-objs.obj64 usr/s...

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all