[Lldb-commits] [lldb] r135363 - in /lldb/trunk: include/lldb/Core/ include/lldb/Target/ source/ source/Core/ source/Plugins/Process/MacOSX-Kernel/ source/Plugins/Process/MacOSX-User/source/ source/Plugins/Process/gdb-remote/ source/Target/

[Matt Johnson]

Hi all,

struct sockaddr and struct sockaddr_in don't have sa_len and sin_len 
members, respectively in glibc/Ubuntu 11.04, breaking the build on r135363:

ConnectionFileDescriptor.cpp: In member function ‘virtual size_t 
lldb_private::ConnectionFileDescriptor::Read(void*, size_t, uint32_t, 
lldb::ConnectionStatus&, lldb_private::Error*)’:
ConnectionFileDescriptor.cpp:289:57: error: ‘struct sockaddr’ has no 
member named ‘sa_len’
ConnectionFileDescriptor.cpp: In member function ‘virtual size_t 
lldb_private::ConnectionFileDescriptor::Write(const void*, size_t, 
lldb::ConnectionStatus&, lldb_private::Error*)’:
ConnectionFileDescriptor.cpp:410:59: error: ‘struct sockaddr’ has no 
member named ‘sa_len’
ConnectionFileDescriptor.cpp: In member function ‘lldb::ConnectionStatus 
lldb_private::ConnectionFileDescriptor::ConnectUDP(const char*, 
lldb_private::Error*)’:
ConnectionFileDescriptor.cpp:850:13: error: ‘struct sockaddr_in’ has no 
member named ‘sin_len’

glibc provides equivalent functionality to sa_len with a macro SA_LEN, 
which looks at the sa_family member to determine the length (see 
http://lists.debian.org/debian-ipv6/2001/06/msg00015.html). Fixing the 
build under glibc would involve #ifdefing out the first use of sa_len 
and the only use of sin_len, and replacing the second use of sa_len with 
the SA_LEN() macro.

I'm not submitting a patch yet because I wanted to ask how we want to 
test for sa_len and sin_len. Other projects have done it using autoconf 
macros (see http://archives.seul.org/or/cvs/Jan-2009/msg00014.html 
http://hackage.haskell.org/trac/ghc/ticket/2326 ), but I can't figure 
out on inspection exactly how lldb's Makefile is generated. I suspect it 
relies on llvm's configure script, but am not sure. If so, that would be 
the appropriate place to put the member checks, but this may require 
lldb to roll forward its frozen llvm version.

Thoughts?

Best,
Matt