clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

Alex Denisov via cfe-dev
Dear developers,

As of r307243, clang++ seems to have the __is_aggregate() builtin
macro, but __has_builtin(__is_aggregate) returns false.  This is
rendering std::is_aggregate from libstdc++-7 unusable with clang++.

I have tested the code below with clang-5.0=5.0~svn307243-1 package from
apt.llvm.org on a debian unstable box.

#include <iostream>

int main(void){
        std::cout << "__has_builtin(__is_aggregate) = " <<  __has_builtin(__is_aggregate) << std::endl;
        std::cout << "__is_aggregate(int[42]) = " <<  __is_aggregate(int[42]) << std::endl;
        std::cout << "__is_aggregate(std::string) = " <<  __is_aggregate(std::string) << std::endl;
        return 0;
}

result:
__has_builtin(__is_aggregate) = 0
__is_aggregate(int[42]) = 1
__is_aggregate(std::string) = 0

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

Alex Denisov via cfe-dev
On 07/07/2017 03:23 AM, Katsuhiko Nishimra via cfe-dev wrote:
> Dear developers,
>
> As of r307243, clang++ seems to have the __is_aggregate() builtin
> macro, but __has_builtin(__is_aggregate) returns false.  This is
> rendering std::is_aggregate from libstdc++-7 unusable with clang++.
>

Is this a regression?  Also, can you file a bug at bugs.llvm.org and
add me as a cc: [hidden email].

Thanks,
Tom

> I have tested the code below with clang-5.0=5.0~svn307243-1 package from
> apt.llvm.org on a debian unstable box.
>
> #include <iostream>
>
> int main(void){
> std::cout << "__has_builtin(__is_aggregate) = " <<  __has_builtin(__is_aggregate) << std::endl;
> std::cout << "__is_aggregate(int[42]) = " <<  __is_aggregate(int[42]) << std::endl;
> std::cout << "__is_aggregate(std::string) = " <<  __is_aggregate(std::string) << std::endl;
> return 0;
> }
>
> result:
> __has_builtin(__is_aggregate) = 0
> __is_aggregate(int[42]) = 1
> __is_aggregate(std::string) = 0
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

Alex Denisov via cfe-dev
In reply to this post by Alex Denisov via cfe-dev
On 7 July 2017 at 00:23, Katsuhiko Nishimra via cfe-dev <[hidden email]> wrote:
Dear developers,

As of r307243, clang++ seems to have the __is_aggregate() builtin
macro, but __has_builtin(__is_aggregate) returns false.  This is
rendering std::is_aggregate from libstdc++-7 unusable with clang++.

__has_builtin detects builtin functions. __is_aggregate is not a builtin function -- it's not a function at all, since it takes a type, not a value. But if libstdc++7 is assuming that __has_builtin can be used to detect type trait keywords, perhaps we should make it so; it's not unreasonable to expect it to be usable for this purpose.

Would you be interested in providing a patch to Clang to implement this?

I have tested the code below with clang-5.0=5.0~svn307243-1 package from
apt.llvm.org on a debian unstable box.

#include <iostream>

int main(void){
        std::cout << "__has_builtin(__is_aggregate) = " <<  __has_builtin(__is_aggregate) << std::endl;
        std::cout << "__is_aggregate(int[42]) = " <<  __is_aggregate(int[42]) << std::endl;
        std::cout << "__is_aggregate(std::string) = " <<  __is_aggregate(std::string) << std::endl;
        return 0;
}

result:
__has_builtin(__is_aggregate) = 0
__is_aggregate(int[42]) = 1
__is_aggregate(std::string) = 0

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

Alex Denisov via cfe-dev
On Fri, Jul 07, 2017 at 12:50:24PM -0700, Richard Smith wrote:
> __has_builtin detects builtin functions. __is_aggregate is not a builtin
> function -- it's not a function at all, since it takes a type, not a value.
> But if libstdc++7 is assuming that __has_builtin can be used to detect type
> trait keywords, perhaps we should make it so; it's not unreasonable to
> expect it to be usable for this purpose.

I see. Sorry to have misunderstood.
>
> Would you be interested in providing a patch to Clang to implement this?

I don't know much about Clang's codebase, so I think it's better to send
one to libstdc++. But how can I detect if __is_aggregate macro is
usable? I've tried #ifdef directive but with no luck.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

Alex Denisov via cfe-dev
On 8 July 2017 at 06:16, Katsuhiko Nishimra <[hidden email]> wrote:
On Fri, Jul 07, 2017 at 12:50:24PM -0700, Richard Smith wrote:
> __has_builtin detects builtin functions. __is_aggregate is not a builtin
> function -- it's not a function at all, since it takes a type, not a value.
> But if libstdc++7 is assuming that __has_builtin can be used to detect type
> trait keywords, perhaps we should make it so; it's not unreasonable to
> expect it to be usable for this purpose.

I see. Sorry to have misunderstood.
>
> Would you be interested in providing a patch to Clang to implement this?

I don't know much about Clang's codebase, so I think it's better to send
one to libstdc++. But how can I detect if __is_aggregate macro is
usable? I've tried #ifdef directive but with no luck.

I think !__is_identifier(__is_aggregate) is the only way we have to detect this right now.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang++: std::is_aggregate unusable with clang-5.0/libstdc++-7

Alex Denisov via cfe-dev
I've passed this information Jonathan Wakely so that he can correct it.

/Eric

On Tue, Jul 11, 2017 at 7:02 AM, Richard Smith via cfe-dev <[hidden email]> wrote:
On 8 July 2017 at 06:16, Katsuhiko Nishimra <[hidden email]> wrote:
On Fri, Jul 07, 2017 at 12:50:24PM -0700, Richard Smith wrote:
> __has_builtin detects builtin functions. __is_aggregate is not a builtin
> function -- it's not a function at all, since it takes a type, not a value.
> But if libstdc++7 is assuming that __has_builtin can be used to detect type
> trait keywords, perhaps we should make it so; it's not unreasonable to
> expect it to be usable for this purpose.

I see. Sorry to have misunderstood.
>
> Would you be interested in providing a patch to Clang to implement this?

I don't know much about Clang's codebase, so I think it's better to send
one to libstdc++. But how can I detect if __is_aggregate macro is
usable? I've tried #ifdef directive but with no luck.

I think !__is_identifier(__is_aggregate) is the only way we have to detect this right now.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Gain Addresses from a Debug file

Alex Denisov via cfe-dev
In reply to this post by Alex Denisov via cfe-dev
Dear friendly Clang-World,

currently I try some variation of a Debugger. I have one process, which starts another process and gains access to its memory. Like a debugger, this process now should read the value of a global variable directly from the other process. But I don't know the address. So I pleased the clang-cl compiler to generate me a dwarf-debug-file. But in the end, I will have only dwarf files for the .obj-files, but the .exe will have a pdb-file. Using the llvm pdb-dump didn't help me finding the address, because the application will crash while dumping. The single-dwarf file for my object file didn't helped too. So I wanted to ask:

1.) Is there a way how I could gain the address of the global variable from any debug-format under Windows using clang-cl?
2.) Can I use a single dwarf-file with its .obj-file to gain an address? This would be interessting for jitting this obj-file.

Kind regards
Björn Gaier
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789
Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Gain Addresses from a Debug file

Alex Denisov via cfe-dev
1. With a PDB, you can use the DbgHelp library on Windows to enumerate the executable's symbols and their relative addresses within the executable (see http://bit.ly/2vD5aG1)
2. No. Assembling object files into an executable is not a one-to-one thing. Functions are moved around, duplicates and unused deleted, and so forth. Since the linker doesn't store this mapping -- except in the form of a final debug data for the executable -- mapping the individual objects' debug data onto the executable is generally neither feasible nor recommended.



- ½

On 28 August 2017 at 08:22, via cfe-dev <[hidden email]> wrote:
Dear friendly Clang-World,

currently I try some variation of a Debugger. I have one process, which starts another process and gains access to its memory. Like a debugger, this process now should read the value of a global variable directly from the other process. But I don't know the address. So I pleased the clang-cl compiler to generate me a dwarf-debug-file. But in the end, I will have only dwarf files for the .obj-files, but the .exe will have a pdb-file. Using the llvm pdb-dump didn't help me finding the address, because the application will crash while dumping. The single-dwarf file for my object file didn't helped too. So I wanted to ask:

1.) Is there a way how I could gain the address of the global variable from any debug-format under Windows using clang-cl?
2.) Can I use a single dwarf-file with its .obj-file to gain an address? This would be interessting for jitting this obj-file.

Kind regards
Björn Gaier
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789
Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Clang/LLVM JIT - When to use "registerEHFrames()"

Alex Denisov via cfe-dev
In reply to this post by Alex Denisov via cfe-dev
Hello friendly Clang-World,

I was experimenting with Clang and the JIT capabilities of LLVM. Most of my attempts were successfully but, I still fail miserably at exceptions. Doing research I found the function "registerEHFrames()" which should assist me supporting exceptions - but sadly the documentation I found wasn't helpful.
I looked at into the "notifyObjectLoaded" function and discovered that there appear some symbol names starting with "$" - I expected them to be connected to my try and catch block. But what now? As usually, at this point I have there names, but can't get there address to register them with the "registerEHFrames()" function. Also the JITTER still wants an address for "??_7type_info@@6B@" which is the virtual table of the type_info struct.

Confusing! So friendly Clang-World, could you please help?

Not so important - but has the dragon which decorates clang and LLVM a name?

Kind regards
Björn
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789
Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev