remote to debugserver

When I attach to an osx debugserver running on a remote computer, sometimes my breakpoints properly get bound, sometimes they don't. I define my breakpoints before connecting to the remote server. Is this a known issue or should I try and dig deeper? It seems to work every time i step through the DynamicLoader*::OnAttach(); it's almost like I'm connecting to debugserver too soon. If this is a known issue, is there a workaround? If not, where can I look to narrow this down?

Run this before attaching:

(lldb) log enable lldb dyld

This will enable logging for the dynamic loader plug-ins. It will make the DynamicLoaderMacOSX log all the shared libraries it finds. Run it successfully and save the output. Then save the output from when it fails and compare the two.

Greg

Op 17-10-2012 22:54, Greg Clayton schreef:

When I attach to an osx debugserver running on a remote computer,
sometimes my breakpoints properly get bound, sometimes they don't.
I define my breakpoints before connecting to the remote server. Is
this a known issue or should I try and dig deeper? It seems to work
every time i step through the DynamicLoader*::OnAttach(); it's
almost like I'm connecting to debugserver too soon. If this is a
known issue, is there a workaround? If not, where can I look to
narrow this down?

Run this before attaching:

(lldb) log enable lldb dyld

This will enable logging for the dynamic loader plug-ins. It will
make the DynamicLoaderMacOSX log all the shared libraries it finds.
Run it successfully and save the output. Then save the output from
when it fails and compare the two.

It ended up being something much different. On Windows filenames aren't case sensitive; so for some reason sometimes I got a path with the proper caps, other times a path with a lowercase element in it. FileSpec needs a case insensitive compare for == on Windows (will add in the windows branch after some more testing)

But can’t Windows have case-sensitive filesystems? I don’t think changing == blindly is good for this case.
But we have the problem of not knowing what FS we have and if it’s case-sensitive or not.

If we’re trying to find existing files, can’t we stat() them (or something equivalent on windows)?

Regards,

Filipe

We don't do any case comparing at all with FileSpec and the performance will be horrible if we enable it. FileSpec objects have 2 ConstStrings: 1 for the dir, 1 for the basename. This means that comparing FileSpec objects are one or two pointer compares since the strings are unique and the pointer values states equality.

I would be very careful what you do, unless it is a host wide setting (i.e. windows never has case sesitive FS, or always has it).

MacOSX can run with and without case sensitive file systems on a per volume basis, so it really isn't easy to enable/disable this for MacOSX.

If you have a case where there is never case sensitivity, then you could lowercase all string values as they get put into the FileSpec, but this will make the LLDB output ugly and not match the output from the debug info, and also would require that all paths be resolved to their volume so you would know when the filespec is on a case sensitive file system...

I would skip doing anything if you can, otherwise, we need to have a discussion how to handle this.

Op 18-10-2012 02:54, Greg Clayton schreef:

We don't do any case comparing at all with FileSpec and the
performance will be horrible if we enable it. FileSpec objects have 2
ConstStrings: 1 for the dir, 1 for the basename. This means that
comparing FileSpec objects are one or two pointer compares since the
strings are unique and the pointer values states equality.

I would be very careful what you do, unless it is a host wide setting
(i.e. windows never has case sesitive FS, or always has it).

MacOSX can run with and without case sensitive file systems on a per
volume basis, so it really isn't easy to enable/disable this for
MacOSX.

If you have a case where there is never case sensitivity, then you
could lowercase all string values as they get put into the FileSpec,
but this will make the LLDB output ugly and not match the output from
the debug info, and also would require that all paths be resolved to
their volume so you would know when the filespec is on a case
sensitive file system...

I would skip doing anything if you can, otherwise, we need to have a
discussion how to handle this.

You're right (both of you). (And I found out this morning that Windows CAN be case sensitive, although it rarely is) I'll try and find out where this bad path came from in the first place and reply here.

Op 18-10-2012 09:15, Carlo Kok schreef:

Op 18-10-2012 02:54, Greg Clayton schreef:

We don't do any case comparing at all with FileSpec and the
performance will be horrible if we enable it. FileSpec objects have 2
ConstStrings: 1 for the dir, 1 for the basename. This means that
comparing FileSpec objects are one or two pointer compares since the
strings are unique and the pointer values states equality.

I would be very careful what you do, unless it is a host wide setting
(i.e. windows never has case sesitive FS, or always has it).

MacOSX can run with and without case sensitive file systems on a per
volume basis, so it really isn't easy to enable/disable this for
MacOSX.

If you have a case where there is never case sensitivity, then you
could lowercase all string values as they get put into the FileSpec,
but this will make the LLDB output ugly and not match the output from
the debug info, and also would require that all paths be resolved to
their volume so you would know when the filespec is on a case
sensitive file system...

I would skip doing anything if you can, otherwise, we need to have a
discussion how to handle this.

You're right (both of you). (And I found out this morning that Windows
CAN be case sensitive, although it rarely is) I'll try and find out
where this bad path came from in the first place and reply here.

I managed to solve this without any changes to LLDB. What happened was that Visual Studio told my compiler that the source files were in

C:\Users\carlokok\documents\...
while it told the Visual Studio Debugger api said they were in:
C:\Users\carlokok\Documents\

Now I resolve the path before passing it on to LLVM and LLDB

thanks!