Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Pavel Labath via lldb-commits]

On 11/12/2018 23:54, Zachary Turner wrote:



On Tue, Dec 11, 2018 at 11:57 AM Pavel Labath > wrote:


The part I know nothing about is whether something similar could be
done
for PE/COFF files (and I'll need something like that there too).
Adrian,
Zachary, what is the relation ship between "image base" of an object
file and its sections? Is there any way we could arrange so that the
base address of a module always belongs to one of its sections?


Historically, an image base of N was used as a way to tell the loader 
"map the file in so that byte 0 of the file is virtual address N in the 
process's address space".  as in *((char *)N) would be the first byte of 
the file in a running process.  Then, everything else in the file is 
written as an offset from N.  This includes section addresses.  So for 
example, if we use dumpbin on a simple executable we can see something 
like this:


Dump of file bin\count.exe

PE signature found

File Type: EXECUTABLE IMAGE

OPTIONAL HEADER VALUES
                   ...
        14000 image base (00014000 to 000140011FFF)
                   ...
SECTION HEADER #1
    .text name
     1000 virtual address (000140001000 to 0001400089AE)

So under this scheme, the first byte of the first section would be at 
virtual address 000140001000 in the running process.


Later, ASLR came along and threw a wrench in all of that, and so these 
days the image base is mostly meaningless.  The loader will probably 
never actually load your module at the address specified in image base.  
But the rest of the rules still hold true.  Wherever it *does* load your 
module, the first byte of .text will still be at offset 1000 from that.


So, if you want to return this value from the PE/COFF header, or even if 
you want to return the actual address that the module was loaded at, 
then no, it will never belong to any section (because the bytes at that 
address will be the PE/COFF file header).


Does this make sense?


I think it does.

I am aware that this address is not going to represent a valid address 
in target memory (the same is true for elf and macho targets), but what 
we're trying to ensure is that when we take this address, and ask the 
running target to give us the "load" address for it, it will return the 
actual place in memory (and conversely if the target is not running it 
should give us an invalid address instead of returning something bogus.


So, if I understand correctly, the PE/COFF file will always be loaded 
into one contiguous chunk of memory, ranging from ImageBase (modulo 
ASLR) to ImageBase+SizeOfImage. Then various sections are mapped into 
that range (according to their RVAs).


If that's the case, then we could model this as one big 
segment/container section/whateever, and the individual (loadable) 
sections would be sub-sections of that. Apart from solving my current 
problem, this should also improve the address lookup for these modules. 
E.g. right now if you ask lldb to lookup the address corresponding to 
the memory image of the header, it will say it does not belong anywhere, 
but that address is clearly associated with the module.


I'll try looking at what kind of changes are needed to make this happen. 
I'll start with the elf case, as I am more familiar with that (and it'll 
probably be more complicated).


thanks,
pl
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Zachary Turner via lldb-commits]

On Tue, Dec 11, 2018 at 11:57 AM Pavel Labath  wrote:

> The part I know nothing about is whether something similar could be done
> for PE/COFF files (and I'll need something like that there too). Adrian,
> Zachary, what is the relation ship between "image base" of an object
> file and its sections? Is there any way we could arrange so that the
> base address of a module always belongs to one of its sections?
>
>
Historically, an image base of N was used as a way to tell the loader "map
the file in so that byte 0 of the file is virtual address N in the
process's address space".  as in *((char *)N) would be the first byte of
the file in a running process.  Then, everything else in the file is
written as an offset from N.  This includes section addresses.  So for
example, if we use dumpbin on a simple executable we can see something like
this:

Dump of file bin\count.exe

PE signature found

File Type: EXECUTABLE IMAGE

OPTIONAL HEADER VALUES
  ...
   14000 image base (00014000 to 000140011FFF)
  ...
SECTION HEADER #1
   .text name
1000 virtual address (000140001000 to 0001400089AE)

So under this scheme, the first byte of the first section would be at
virtual address 000140001000 in the running process.

Later, ASLR came along and threw a wrench in all of that, and so these days
the image base is mostly meaningless.  The loader will probably never
actually load your module at the address specified in image base.  But the
rest of the rules still hold true.  Wherever it *does* load your module,
the first byte of .text will still be at offset 1000 from that.

So, if you want to return this value from the PE/COFF header, or even if
you want to return the actual address that the module was loaded at, then
no, it will never belong to any section (because the bytes at that address
will be the PE/COFF file header).

Does this make sense?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Greg Clayton via lldb-commits]

> On Dec 11, 2018, at 11:58 AM, Pavel Labath  wrote:
> 
> On 11/12/2018 20:39, Jim Ingham wrote:
>> Sections can have parents.  In MachO the text and data sections are actually 
>> contained in the TEXT and DATA segments respectively.  LLDB represents this 
>> by having an lldb_private::Section for the segment, and then all the 
>> sections in that segment are children of the parent Section (the MachO 
>> segment).  All the code that looks up addresses expects to potentially 
>> traverse this hierarchy.
>> It seems to me that what you are describing should fit in the nesting model?
>> Jim
>>  
> 
> Hmm.. that's an interesting idea. I'll have to think about that.
> 

I think having the program header segments being top level sections in ELF, 
with the sections headers contained within them would fix things correctly and 
allow us to give out as section + offset base address. 

> Does MachO enforce somehow that every section is fully contained in one 
> segment?

yes


> Because while that is true for elf in general, it is not a requirement, and 
> it is possible to create functional executables (though I think I would have 
> to use a hex editor for that) where one segment contains only a half of some 
> section. But that might not be a big issue, as I think most tools will choke 
> on files like this, so if we do something suboptimal here, it shouldn't be 
> too bad.

I would be surprised to see this kind of thing, though it could exist. We can 
easily just make two top level sections when this happens so it can remain 
consistent?

> 
> The other hickup I can think of is that sometimes (and this happens in 
> perfectly valid files too) one section is present in multiple segments. For 
> example .eh_frame will be present in a "LOAD" segment (so it ends up in 
> memory), but it will also be present in a special "GNU_EH_FRAME" segment (not 
> sure why, but I guess it's to make it easier for someone to find it). But I 
> think I can get around that by only creating these "container" sections for 
> LOAD segments.

I agree, LOAD segments would be created, and any sections that would fit inside 
of those will be put there, otherwise, they are top level sections?
> 
> 
> The part I know nothing about is whether something similar could be done for 
> PE/COFF files (and I'll need something like that there too). Adrian, Zachary, 
> what is the relation ship between "image base" of an object file and its 
> sections? Is there any way we could arrange so that the base address of a 
> module always belongs to one of its sections?

That is the key question.

> 
> pl

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

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Jim Ingham via lldb-commits]

In MachO a segment fully contains its sections and a section can only be in one 
segment.  I don't remember how much the lldb Section nesting code enforces 
this.  It would be weird to have two Sections at the same level overlap, I 
don't see any "GetSectionsForAddress(lldb::addr_t address)" API's so I don't 
think we're ready to handle that.

Maybe we could start marking sections as "duplicate" and only handing out the 
original one when doing lldb::addr_t -> Section lookups?

Jim


> On Dec 11, 2018, at 11:58 AM, Pavel Labath  wrote:
> 
> On 11/12/2018 20:39, Jim Ingham wrote:
>> Sections can have parents.  In MachO the text and data sections are actually 
>> contained in the TEXT and DATA segments respectively.  LLDB represents this 
>> by having an lldb_private::Section for the segment, and then all the 
>> sections in that segment are children of the parent Section (the MachO 
>> segment).  All the code that looks up addresses expects to potentially 
>> traverse this hierarchy.
>> It seems to me that what you are describing should fit in the nesting model?
>> Jim
>>  
> 
> Hmm.. that's an interesting idea. I'll have to think about that.
> 
> Does MachO enforce somehow that every section is fully contained in one 
> segment? Because while that is true for elf in general, it is not a 
> requirement, and it is possible to create functional executables (though I 
> think I would have to use a hex editor for that) where one segment contains 
> only a half of some section. But that might not be a big issue, as I think 
> most tools will choke on files like this, so if we do something suboptimal 
> here, it shouldn't be too bad.
> 
> The other hickup I can think of is that sometimes (and this happens in 
> perfectly valid files too) one section is present in multiple segments. For 
> example .eh_frame will be present in a "LOAD" segment (so it ends up in 
> memory), but it will also be present in a special "GNU_EH_FRAME" segment (not 
> sure why, but I guess it's to make it easier for someone to find it). But I 
> think I can get around that by only creating these "container" sections for 
> LOAD segments.
> 
> 
> The part I know nothing about is whether something similar could be done for 
> PE/COFF files (and I'll need something like that there too). Adrian, Zachary, 
> what is the relation ship between "image base" of an object file and its 
> sections? Is there any way we could arrange so that the base address of a 
> module always belongs to one of its sections?
> 
> pl

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

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Pavel Labath via lldb-commits]

On 11/12/2018 20:39, Jim Ingham wrote:

Sections can have parents.  In MachO the text and data sections are actually 
contained in the TEXT and DATA segments respectively.  LLDB represents this by 
having an lldb_private::Section for the segment, and then all the sections in 
that segment are children of the parent Section (the MachO segment).  All the 
code that looks up addresses expects to potentially traverse this hierarchy.

It seems to me that what you are describing should fit in the nesting model?

Jim
  


Hmm.. that's an interesting idea. I'll have to think about that.

Does MachO enforce somehow that every section is fully contained in one 
segment? Because while that is true for elf in general, it is not a 
requirement, and it is possible to create functional executables (though 
I think I would have to use a hex editor for that) where one segment 
contains only a half of some section. But that might not be a big issue, 
as I think most tools will choke on files like this, so if we do 
something suboptimal here, it shouldn't be too bad.


The other hickup I can think of is that sometimes (and this happens in 
perfectly valid files too) one section is present in multiple segments. 
For example .eh_frame will be present in a "LOAD" segment (so it ends up 
in memory), but it will also be present in a special "GNU_EH_FRAME" 
segment (not sure why, but I guess it's to make it easier for someone to 
find it). But I think I can get around that by only creating these 
"container" sections for LOAD segments.



The part I know nothing about is whether something similar could be done 
for PE/COFF files (and I'll need something like that there too). Adrian, 
Zachary, what is the relation ship between "image base" of an object 
file and its sections? Is there any way we could arrange so that the 
base address of a module always belongs to one of its sections?


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

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Jim Ingham via lldb-commits]

Sections can have parents.  In MachO the text and data sections are actually 
contained in the TEXT and DATA segments respectively.  LLDB represents this by 
having an lldb_private::Section for the segment, and then all the sections in 
that segment are children of the parent Section (the MachO segment).  All the 
code that looks up addresses expects to potentially traverse this hierarchy.

It seems to me that what you are describing should fit in the nesting model?

Jim
 
> On Dec 11, 2018, at 11:31 AM, Pavel Labath  wrote:
> 
> On 11/12/2018 20:10, Jim Ingham via Phabricator wrote:
>> jingham added a comment.
>> In D55356#1327280 , @clayborg wrote:
>>> In D55356#1327242 , @labath wrote:
>>> 
 In D55356#1327224 , @clayborg 
 wrote:
 
> In D55356#1327099 , @labath 
> wrote:
> 
>> Actually, this now causes an lldb-mi test to fail, but it's not clear to 
>> me if the problem is in the test, or this patch. This issue happens when 
>> lldb-mi is printing the "library loaded" message after a module gets 
>> added to a not-yet-running target. It tries to print the load address by 
>> first getting the base address and then converting that to a load 
>> address.
>> 
>> Before this patch, that would always fail, because well.. ELF and PECOFF 
>> had this function unimplemented, and for MachO the base address was 
>> section-relative, and so it wasn't resolved to a load address without 
>> the section being loaded. However, with this patch, in the ELF (and 
>> presumably PECOFF) case, the load address is not section-relative and so 
>> the `GetLoadAddress` function happily returns the address.
>> 
>> Is this the expected behavior here? (i.e., 
>> object_file->GetLoadAddress().GetLoadAddress(target) returning a valid 
>> value even though the target is not running)
> 
> 
> Not unless someone has manually set the section load address in the test?
 
 
 The test is not setting the load address manually. This simply falls out 
 of how `Address::GetLoadAddress`  is implemented:
 
   addr_t Address::GetLoadAddress(Target *target) const {
 SectionSP section_sp(GetSection());
 if (section_sp) {
   ...
 } else {
   // We don't have a section so the offset is the load address
   return m_offset;
 }
   }
 
 
 So, where's the bug here? It's not clear to me how to change 
 `Address::GetLoadAddress` to do something different than what it is doing 
 now.
>>> 
>>> 
>>> So this is a bug really. When there is no section, we should specify what 
>>> the m_offset is using lldb_private::AddressType in maybe a new ivar name 
>>> "m_offset_type". Then GetBaseAddress() would specify eAddressTypeFile. And 
>>> the above code would become:
>>> 
>>>  
>>> addr_t Address::GetLoadAddress(Target *target) const {
>>> 
>>>   SectionSP section_sp(GetSection());
>>>   if (section_sp) {
>>> ...
>>>   } else if (m_offset_type == eAddressTypeLoad) {
>>> // We don't have a section so the offset is the load address
>>> return m_offset;
>>>   }
>>> 
>>> }
>>> 
>>>   We just need to be careful and see if we can not make 
>>> lldb_private::Address get any bigger byte size wise if we can at all avoid 
>>> it.
>> I must be missing something.  If there's a file around so that we can 
>> express this address relative to the file, why would it ever not be 
>> expressed as a section + offset?  If there's not a file around, then what 
>> does it mean to say this address ie eAddressTypeFile but we don't know the 
>> file?
> 
> I think the issue here is the difference in how elf and MachO files are 
> loaded. Elf has this strange dual view of the file, where the same data is 
> represented both as "sections", and "segments". Sections are the thing we all 
> know (.text, .data, .debug_info, etc.), and are used by most tools (lldb, 
> linker, ...). However, this is *not* what the kernel uses when it loads a 
> binary into memory. The loader uses "segments" instead.
> 
> It is segments who describe where will a piece of file be loaded into memory. 
> Normally, segments span one or more sections, but this is not a requirement. 
> And almost always segments will contain some additional data besides section 
> content. This data is generally "junk" but it is there because it enables the 
> linker to "pack" the elf file more efficiently.
> 
> A typical elf file might look something like
> ---
> | elf header  |
> ---
> | segment headers |
> ---
> | .text   |
> ---
> | other sections  |
> ---
> | section headers |
> ---
> 
> The segment headers might say "load everything from the start of 

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Pavel Labath via lldb-commits]

On 11/12/2018 20:10, Jim Ingham via Phabricator wrote:

jingham added a comment.

In D55356#1327280 , @clayborg wrote:


In D55356#1327242 , @labath wrote:


In D55356#1327224 , @clayborg wrote:


In D55356#1327099 , @labath wrote:


Actually, this now causes an lldb-mi test to fail, but it's not clear to me if the 
problem is in the test, or this patch. This issue happens when lldb-mi is printing the 
"library loaded" message after a module gets added to a not-yet-running target. 
It tries to print the load address by first getting the base address and then converting 
that to a load address.

Before this patch, that would always fail, because well.. ELF and PECOFF had 
this function unimplemented, and for MachO the base address was 
section-relative, and so it wasn't resolved to a load address without the 
section being loaded. However, with this patch, in the ELF (and presumably 
PECOFF) case, the load address is not section-relative and so the 
`GetLoadAddress` function happily returns the address.

Is this the expected behavior here? (i.e., 
object_file->GetLoadAddress().GetLoadAddress(target) returning a valid value 
even though the target is not running)



Not unless someone has manually set the section load address in the test?



The test is not setting the load address manually. This simply falls out of how 
`Address::GetLoadAddress`  is implemented:

   addr_t Address::GetLoadAddress(Target *target) const {
 SectionSP section_sp(GetSection());
 if (section_sp) {
   ...
 } else {
   // We don't have a section so the offset is the load address
   return m_offset;
 }
   }


So, where's the bug here? It's not clear to me how to change 
`Address::GetLoadAddress` to do something different than what it is doing now.



So this is a bug really. When there is no section, we should specify what the m_offset is 
using lldb_private::AddressType in maybe a new ivar name "m_offset_type". Then 
GetBaseAddress() would specify eAddressTypeFile. And the above code would become:

  


addr_t Address::GetLoadAddress(Target *target) const {

   SectionSP section_sp(GetSection());
   if (section_sp) {
 ...
   } else if (m_offset_type == eAddressTypeLoad) {
 // We don't have a section so the offset is the load address
 return m_offset;
   }

}

   We just need to be careful and see if we can not make lldb_private::Address 
get any bigger byte size wise if we can at all avoid it.



I must be missing something.  If there's a file around so that we can express 
this address relative to the file, why would it ever not be expressed as a 
section + offset?  If there's not a file around, then what does it mean to say 
this address ie eAddressTypeFile but we don't know the file?




I think the issue here is the difference in how elf and MachO files are 
loaded. Elf has this strange dual view of the file, where the same data 
is represented both as "sections", and "segments". Sections are the 
thing we all know (.text, .data, .debug_info, etc.), and are used by 
most tools (lldb, linker, ...). However, this is *not* what the kernel 
uses when it loads a binary into memory. The loader uses "segments" instead.


It is segments who describe where will a piece of file be loaded into 
memory. Normally, segments span one or more sections, but this is not a 
requirement. And almost always segments will contain some additional 
data besides section content. This data is generally "junk" but it is 
there because it enables the linker to "pack" the elf file more efficiently.


A typical elf file might look something like
---
| elf header  |
---
| segment headers |
---
| .text   |
---
| other sections  |
---
| section headers |
---

The segment headers might say "load everything from the start of file to 
the end of .text section at address 0x4". So the load address of 
this file (and the base for all kinds of offsets) would be "0x4", 
but that does not correspond to any section (the file address of the 
.text section would probably be something like 0x40123).


So, it almost sounds to me like we would need some kind of a 
module-relative (in addition to section-relative) address. Then, this 
address would be represented as "module+0", and GetLoadAddress(target) 
could translate that the same way as it does section-relative addresses.


Though that may be overkill here. For my purposes it would be sufficient 
to just have a function which always returns an file address (regardless 
of whether it points to a section or not), and I can use it to compute 
offsets (kind of like my original patch did). We could keep the 
Module.GetBaseAddress returning LLDB_INVALID_ADDRESS for cases when the 
base address cannot be 

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Jim Ingham via lldb-commits]

The current behavior is definitely correct.  An Address without a section is 
generally going to be something like a stack or heap address.  Those definitely 
have load addresses of whatever their value is.

I'm not sure what it means to have a file address represented as an offset not 
a section with offset.  That might end up matching some address in an object 
file on load, but that's entirely an accident from lldb's perspective.  Can you 
not make this as a section relative thing when it is a file address?

Jim


> On Dec 11, 2018, at 10:42 AM, Pavel Labath  wrote:
> 
> On 11/12/2018 19:17, Jim Ingham wrote:
>> It the section isn't in the target's SectionLoadList, then GetLoadAddress 
>> should return LLDB_INVALID_ADDRESS.  I.e. this bit from 
>> Section::GetLoadBaseAddress:
>> load_base_addr = target->GetSectionLoadList().GetSectionLoadAddress(
>> const_cast(this)->shared_from_this());
>> should return LLDB_INVALID_ADDRESS because the section isn't in the load 
>> list.
>> Are we putting sections in the target's section load list before we've 
>> actually seen them loaded.  I'm pretty sure we shouldn't do that.
>> Jim
> 
> The issue here is that the Address object in question is not backed by any 
> section. It has a null section, and just an offset member.
> In this case Address::GetLoadAddress just decides to return that address as a 
> load address, which I imagine is correct in some situations, but in this case 
> our intention was for this address to represent a file address (which would 
> still need to be adjusted to account for where the module ended up being 
> loaded).
> 
> 

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

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Pavel Labath via lldb-commits]

On 11/12/2018 19:17, Jim Ingham wrote:

It the section isn't in the target's SectionLoadList, then GetLoadAddress 
should return LLDB_INVALID_ADDRESS.  I.e. this bit from 
Section::GetLoadBaseAddress:

 load_base_addr = target->GetSectionLoadList().GetSectionLoadAddress(
 const_cast(this)->shared_from_this());

should return LLDB_INVALID_ADDRESS because the section isn't in the load list.

Are we putting sections in the target's section load list before we've actually 
seen them loaded.  I'm pretty sure we shouldn't do that.

Jim




The issue here is that the Address object in question is not backed by 
any section. It has a null section, and just an offset member.
In this case Address::GetLoadAddress just decides to return that address 
as a load address, which I imagine is correct in some situations, but in 
this case our intention was for this address to represent a file address 
(which would still need to be adjusted to account for where the module 
ended up being loaded).



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

Re: [Lldb-commits] [PATCH] D55356: Add a method to get the "base" file address of an object file

[Jim Ingham via lldb-commits]

It the section isn't in the target's SectionLoadList, then GetLoadAddress 
should return LLDB_INVALID_ADDRESS.  I.e. this bit from 
Section::GetLoadBaseAddress:

load_base_addr = target->GetSectionLoadList().GetSectionLoadAddress(
const_cast(this)->shared_from_this());

should return LLDB_INVALID_ADDRESS because the section isn't in the load list.

Are we putting sections in the target's section load list before we've actually 
seen them loaded.  I'm pretty sure we shouldn't do that.

Jim


> On Dec 11, 2018, at 9:58 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
> labath added a comment.
> 
> In D55356#1327224 , @clayborg wrote:
> 
>> In D55356#1327099 , @labath wrote:
>> 
>>> Actually, this now causes an lldb-mi test to fail, but it's not clear to me 
>>> if the problem is in the test, or this patch. This issue happens when 
>>> lldb-mi is printing the "library loaded" message after a module gets added 
>>> to a not-yet-running target. It tries to print the load address by first 
>>> getting the base address and then converting that to a load address.
>>> 
>>> Before this patch, that would always fail, because well.. ELF and PECOFF 
>>> had this function unimplemented, and for MachO the base address was 
>>> section-relative, and so it wasn't resolved to a load address without the 
>>> section being loaded. However, with this patch, in the ELF (and presumably 
>>> PECOFF) case, the load address is not section-relative and so the 
>>> `GetLoadAddress` function happily returns the address.
>>> 
>>> Is this the expected behavior here? (i.e., 
>>> object_file->GetLoadAddress().GetLoadAddress(target) returning a valid 
>>> value even though the target is not running)
>> 
>> 
>> Not unless someone has manually set the section load address in the test?
> 
> 
> The test is not setting the load address manually. This simply falls out of 
> how `Address::GetLoadAddress`  is implemented:
> 
>  addr_t Address::GetLoadAddress(Target *target) const {
>SectionSP section_sp(GetSection());
>if (section_sp) {
>  ...
>} else {
>  // We don't have a section so the offset is the load address
>  return m_offset;
>}
>  }
> 
> So, where's the bug here? It's not clear to me how to change 
> `Address::GetLoadAddress` to do something different than what it is doing now.
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D55356/new/
> 
> https://reviews.llvm.org/D55356
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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