Re: [lldb-dev] unaligned cast in TCPSocket::Connect

[Pavel Labath via lldb-dev]

fine by me. We should probably also stop using inet_ntoa as it is not
thread-safe (I don't know what is the safe alternative off-hand).

pl

On 13 October 2016 at 19:00, Zachary Turner via lldb-dev
 wrote:
> I believe you are correct.  We should create an in_addr on the stack and
> memcpy into it.
>
> On Thu, Oct 13, 2016 at 10:52 AM Ted Woodward via lldb-dev
>  wrote:
>>
>> TCPSocket::Connect has this line:
>>
>> host_str = ::inet_ntoa (*(struct in_addr
>> *)*host_entry->h_addr_list);
>>
>>
>>
>> host_entry->h_addr_list is a char**, while struct in_addr contains a
>> uint32_t. Casting like this (char * to uint_32t *) could cause a bus error
>> on systems that don’t allow non-aligned loads. I think we need to memcpy the
>> data into a struct in_addr variable.
>>
>>
>>
>> Anyone have any thoughts on this?
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] unaligned cast in TCPSocket::Connect

[Zachary Turner via lldb-dev]

I believe you are correct.  We should create an in_addr on the stack and
memcpy into it.

On Thu, Oct 13, 2016 at 10:52 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> TCPSocket::Connect has this line:
>
> host_str = ::inet_ntoa (*(struct in_addr
> *)*host_entry->h_addr_list);
>
>
>
> host_entry->h_addr_list is a char**, while struct in_addr contains a
> uint32_t. Casting like this (char * to uint_32t *) could cause a bus error
> on systems that don’t allow non-aligned loads. I think we need to memcpy
> the data into a struct in_addr variable.
>
>
>
> Anyone have any thoughts on this?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] unaligned cast in TCPSocket::Connect

[Ted Woodward via lldb-dev]

TCPSocket::Connect has this line:

host_str = ::inet_ntoa (*(struct in_addr
*)*host_entry->h_addr_list);

 

host_entry->h_addr_list is a char**, while struct in_addr contains a
uint32_t. Casting like this (char * to uint_32t *) could cause a bus error
on systems that don't allow non-aligned loads. I think we need to memcpy the
data into a struct in_addr variable.

 

Anyone have any thoughts on this?

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] get function name from dwarf info

[Carlo Kok via lldb-dev]

On 2016-10-12 19:10, Greg Clayton wrote:



We would also need to add a way to get the class type from the member function:

lldb::SBType lldb::SBTypeMemberFunction::GetContainingType();

This would return the class/struct that owns the member function.


So if we just add:

  lldb::SBTypeMemberFunction lldb::SBType::GetMemberFunction();
  lldb::SBType lldb::SBTypeMemberFunction::GetContainingType();

Then you should be able to do what you want. Let me know if you need help with 
this.


Shouldn't that be SBFunction::GetMemberFunction() ?

If you can hint at where this info is stored that would be great. I 
looked at Function but couldn't figure it out.



Besides that, happen to know how I can get the dw_at_name from dwarf 
function to SBFunction? Atm it seems to go through the demangler in 
Function, which fails (there isn't one) and just returns the symbol name 
even though the info is there.

--
Carlo Kok
RemObjects Software
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] add custom vendor commands

[Giusti, Valentina via lldb-dev]

Hello all,

Background: 
Intel CPUs that support MPX have a limited number of bound registers. For any 
program that has more objects than fit into these registers, the bounds must be 
kept elsewhere. For this purpose, Bounds Tables (BT) are stored in application 
memory: for each pointer there is a bound table entry with lower bound, upper 
bound, check pointer value.

It would be convenient for the user to be able to access the BT and possibly 
also manipulate it, through commands like: 'set/show mpx-bounds  
 '.

Is there a way to add customized commands for vendor features, such as this one?
I have seen that CommandObjectCommands has a class to add commands interpreted 
by command interpreter scripts and an interface for command aliases, so I 
wonder if it would make sense to add something else for vendor commands. For 
example, I could create a new class CommandObjectVendor that allows vendors to 
create their own specific commands. In my case, for the MPX bound table, the 
commands could be:

intel show mpx-bounds   

intel set mpx-bounds


Thanks in advance for your help,

- V.


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev