[lldb-dev] [Bug 35860] displaying some long double values causes lldb to crash

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=35860

lab...@google.com changed:

   What|Removed |Added

 CC||lab...@google.com
   Assignee|lldb-dev@lists.llvm.org |lab...@google.com

--- Comment #1 from lab...@google.com ---
Actually, this is a a special case of an "unnormal" value :D
.

I have a proposed fix for this in 

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb test suite on macOS 10.13 (High Sierra)

[Pavel Labath via lldb-dev]

On 2 January 2018 at 19:20, Jim Ingham  wrote:
> This is actually using the same mechanism that Greg was describing, but 
> through a separate route.
>
> With the crashinfo mechanism in place, if a test crashes the crash log will 
> show whatever test was being run at the time of the crash.  This was pretty 
> useful when we were running the testsuite in one process, since then it was 
> pretty hard to figure out where the test crashed.  But now that the runner is 
> in a separate process it doesn't go down when a test crashes, so you can tell 
> at the least which test directory caused the crash.  If we want to make this 
> better we could do something more platform independent to track which test in 
> a particular directory is the current test, and then report that when we see 
> a crash.  But I don't think it is worth much effort keeping the current 
> mechanism alive.

I agree with that. I have created D41871 to delete the hook.

Also, note that the current test runner will already report the full
test case name if we have a crash (except if the crash happens after
the relevant tearDown method finishes, but in that case, the crashinfo
hook would not help either).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Loading object file to target flash memory using vFlashWrite

[Owen Shaw via lldb-dev]

Looks like there was an addition about a year ago to load an object
file to bare metal target memory via "target modules load --load".
https://reviews.llvm.org/D28804

However, this isn't working in my case with openocd and a target that
uses flash memory.  By comparison, gdb loads the object just fine, but
instead of using the M memory write command, it uses vFlashErase,
vFlashWrite, and vFlashDone.

These flash commands don't seem to be supported in lldb.  Any reason
not to add them?

I've got a basic working implementation, which is probably easier to
break into two reviews:

1. Add support for qXfer:memory-map and parse the resulting xml to
determine which memory regions are flash and what their blocksizes are
(required for vFlashErase)
2. Update ProcessGDBRemote::DoWriteMemory to use the flash commands
when writing to a flash region, while continuing to use M when writing
to non-flash regions.

If this sounds like the right track, I'll open a Phabricator review
for #1 to start.

One question I have relates to the load address for object sections.
The current ObjectFile::LoadInMemory implementation will incorrectly
place my .data section at its virtual address in RAM when it really
should be placed at its physical address in flash memory.  I have code
that can place it at the physical address, but it's unclear if that
change is correct for every case.  Does anyone have insight/opinions?

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

Re: [lldb-dev] Loading object file to target flash memory using vFlashWrite

[Greg Clayton via lldb-dev]

> On Jan 9, 2018, at 3:53 PM, Owen Shaw via lldb-dev  
> wrote:
> 
> Looks like there was an addition about a year ago to load an object
> file to bare metal target memory via "target modules load --load".
> https://reviews.llvm.org/D28804
> 
> However, this isn't working in my case with openocd and a target that
> uses flash memory.  By comparison, gdb loads the object just fine, but
> instead of using the M memory write command, it uses vFlashErase,
> vFlashWrite, and vFlashDone.
> 
> These flash commands don't seem to be supported in lldb.  Any reason
> not to add them?
> 
> I've got a basic working implementation, which is probably easier to
> break into two reviews:
> 
> 1. Add support for qXfer:memory-map and parse the resulting xml to
> determine which memory regions are flash and what their blocksizes are
> (required for vFlashErase)
> 2. Update ProcessGDBRemote::DoWriteMemory to use the flash commands
> when writing to a flash region, while continuing to use M when writing
> to non-flash regions.
> 
> If this sounds like the right track, I'll open a Phabricator review
> for #1 to start.

Those two things sound about right. Though we typically don't like to add 
support for something if it isn't used. #1 would add support for 
"qXfer:memory-map", but nothing would use it. So it might be ok to submit #1 
and #2 as one patch. I am open to suggestions from others if they believe 
differently. A patch should have tests for this and I am not sure how to test 
it, but just know that we will want some sort of tests.

> 
> One question I have relates to the load address for object sections.
> The current ObjectFile::LoadInMemory implementation will incorrectly
> place my .data section at its virtual address in RAM when it really
> should be placed at its physical address in flash memory.  I have code
> that can place it at the physical address, but it's unclear if that
> change is correct for every case.  Does anyone have insight/opinions?

Right now we just load things at the virtual address found in the ELF file. Not 
sure if the physical address should be used for everyone as I am not sure of 
exactly who is using this right now. Most of the time when I see ELF files the 
virtual address is equal to the physical address, so it might just be ok. Feel 
free to let us know what you think should happen and submit a patch. If no one 
has any tests that break in response to this, then we can try it and see how 
things go.

Greg

> 
> Thanks,
> Owen
> ___
> 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