similar to: Change in name mangling algorithm?

Dear sambaphiles, I hope someone can help me understand why I see inconsistent name mangling between Samba and Windows 2000. I am running: LINUX: smbd Version 2.2.1a on linux kernel 2.4.18 MAC: Mac OS 9.1; DAVE version 2.5.2 WINDOWS 2000 PROFESSION (ServicePack 2) According to the O'Reilly book, 'Using Samba', given a file named: antidisestablishmentarianism.txt According to

Might be that google is having a case of the Mondays as I googled about bootstrapping gentoo on xen http://soffi.kvadratrot.net/google-xen.png Flames for offtopic greatly appreciated -soffi- -- Kristinn Soffanias Runarsson ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from

2013/2/21 Anton Korobeynikov <anton at korobeynikov.info>: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. I think clang already adds \01 to __stdcall names, so only the LLVM change is remaining. > I do not think that moving whole mangling to clang is a good idea, >

I think so. There have been other reports lately related to this being wrong. http://llvm.org/bugs/show_bug.cgi?id=14410 CC'ing Timur since he might know more about this. On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at klickverbot.at>wrote: > On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: > >> My question: Is there an easy way

On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at free.fr> wrote: >> My question: Is there an easy way of disabling the name-mangling part >> but keep the rest of the CC that I missed? > if you use "\1" + "usual name", it will disable name mangling if you are > lucky. A leading \1 is LLVM's way of saying: leave this name alone! Seems like

Hi all, I run samba 3.6.6 from debian wheezy (version 3.6.6) and i am experiencing some troubles with file name mangling. If i try "dir /x" on a mapped folder it gives me unexpected mangled names: the name mangling matches only the first character and not the first 5 as i expect. For example: if the long file name is LONGFILENAME.TXT, i expect the mangled sholud be something like

Hi All, In this thread we would like to review the built-ins and name mangling approach which we chose for SPIR. Specifically, I think a discussion on the atomics and memcpy should be interesting. *****OpenCL Built-ins Introduction****** OpenCL provides a huge set of utility functions (>6000 built-ins) which are available for the developers of OpenCL. These functions are called built-ins.

Hi, Nikita pointed me to an issue in the full restrict patches, related to name mangling used for llvm-ir functions (See [0, 3]). The problem is the following: Given: %0 = type { i32 } %1 = type { i32 } Creating an intrinsic @llvm.FOO that accepts 'a pointer to %0' cannot be distinguished from the intrinsic accepting 'a pointer to %1': ;For a %0* ptr0, %1* ptr1

The patch looks incorrect. The code just needs to handle \1 properly and clang extended to add explicit \1 to the names which does not require mangling. I do not think that moving whole mangling to clang is a good idea, because then everyone who uses LLVM to call WinApi functions will need to mangle by hands. On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov <timurrrr at google.com>

Hi, I’d like to make sure my understanding of the name mangling in the ORC examples is correct. In the ORC lazy examples, each function gets IR’ed into its own separate LLVM module, and each module is compiled separately. So, in the name resolver, all functions need to be resolved by their mangled name, as they are linked with external linkage. I’m still not clear on what exactly performs the

Anton, what do you think of David's patch with this test case? OK to commit that? On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > The patch looks incorrect. The code just needs to handle \1 properly > and clang extended to add explicit \1 to the names which does not > require mangling. > > I do not think that moving whole

Hi all, I'm currently working on getting our (LDC) compiler to run on Win32/MinGW, now that DW2-style EH is available for it. The D programming language has a feature equivalent to LLVM module level inline assembly, so we need to at least partly follow the x86 D calling convention (http://dlang.org/abi.html). Most notably, the ABI mandates that the callee cleans the stack. On the various

The Identifiers section in the LLVM language manual states: "The "\01" prefix can be used on global variables to suppress mangling." Is this for global variables only, or global values in general, such as functions also? In implementation LLVM seems to have this behavior of suppressing mangling even for functions and aliases. Thanks, Gautam

I've just bumped into a name mangling issue with Samba which I'm sure people have already found before me...... If you create 2 files called moss_burn.bmp & moss_bend.bmp on a Samba share that has been mapped to a drive under windows then a 'dir' in a DOS shell will show that the 8.3 filenames of these two files are identical......MOSS_~UV.BMP... which is not good for legacy

I've installed Samba 3.0.7 (stock Debian package), but I'm having some wierd problems with name mangling. The relevant lines in smb.conf are: preserve case = yes short preserve case = yes mangled names = yes mangle prefix = 5 mangling method = hash2 In a share, I did "touch test-file.GHO" to create a long filename. When I do a "dir" under DOS,

I want all the file-names to be stored on a samba share from my XP clients to be automatically converted to 8.3 syntax, so that i do not have any further problem while transporting those files over to other networks/servers like netware. As for now i am using these below mentioned lines to support file-name mangling over my samba. --------- #I do not want my filenames to be case sensitive,

Hi, I'm cross-posting here from serverfault.com in case anyone can help. I just found a similar question on askubuntu.com also without an answer. Switched recently from W2K3 to Samba4.0.9/CentOS6.4 for our fileshare for WinXP clients. Have an ancient (1995!) piece of software that uses 8.3 filename format. After the switch, long filenames became useless in the context of the

Hi, I've recently ported Pure (http://purelang.bitbucket.org/) to LLVM 3.4, and I've run into a problem. I'm using LLVM on a Linux x86_64 system (Arch). In previous releases llc would automatically mangle identifiers in LLVM assembler source code so that the result could be assembled with the system assembler of the target platform. E.g., if I have LLVM assembler (.ll) code like:

Hi all, According to the SPIR 2.0 spec[1], the name of OpenCL builtins are mangled. However, when I compile OpenCl code with Clang 3.9 with the "spir64-unknown-unknown" target, Clang generates IR without mangling the builtins, e.g. for: __kernel void input_zip_int(__global int *in0) { *in0 = get_global_id(0); } clang generates: define spir_kernel void @input_zip_int(i32

> The Clang mangler, however, does what you want. But, you'll need to > feed it a clang AST in order to get a name out. Depending on the > parameters of your function, this may be easy or hard. By the way, does anyone know of a project which *does* call into Clang's mangling framework from outside? I'd be interested to know purely out of curiosity. Cheers. Tim.