tcf-dev

Re: [tcf-dev] Commit rights for Doug Schaefer have been expired

dschaefer@xxxxxxx (Doug Schaefer) — Fri, 24 May 2013 23:30:28 GMT

Thank you Martin, and good luck everyone!

Sent from my BlackBerry 10 smartphone on the Rogers network.

From: portal on behalf of emo

Sent: Friday, May 24, 2013 7:10 PM

To: tcf-dev@xxxxxxxxxxx

Reply To: TCF Development

Subject: [tcf-dev] Commit rights for Doug Schaefer have been expired

tools.cdt.tcf Committers,
Martin Oberhuber has expired the commit rights for Doug Schaefer
(dschaefer). The reason for this change is:

When Doug stepped down as the TCF project lead a year ago, he announced
that he had no vested interest in TCF any more; I'm thus expiring his
commit rights.

=?UTF-8?Q?I=C3=A2=C2=80=C2=99m?= going to nominate him for committer emeritus though, thanks to the
key role he played in the DSDP restructuring, building up git and Tycho
build support for TCF, tighter integration with the CDT, as well as
shepherding many contributions.

Thanks Doug for everything !

To honor Doug's contributions to the project, Martin Oberhuber has
nominated Doug for Committer Emeritus status.

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev

[tcf-dev] Commit rights for Doug Schaefer have been expired

portal-noreply@xxxxxxx (portal on behalf of emo) — Fri, 24 May 2013 23:10:01 GMT

tools.cdt.tcf Committers,
Martin Oberhuber has expired the commit rights for Doug Schaefer
(dschaefer).  The reason for this change is:

When Doug stepped down as the TCF project lead a year ago, he announced
that he had no vested interest in TCF any more; I'm thus expiring his
commit rights.

=?UTF-8?Q?I=C3=A2=C2=80=C2=99m?= going to nominate him for committer emeritus though, thanks to the
key role he played in the DSDP restructuring, building up git and Tycho
build support for TCF, tighter integration with the CDT, as well as
shepherding many contributions.

Thanks Doug for everything !

To honor Doug's contributions to the project, Martin Oberhuber has
nominated Doug for Committer Emeritus status.

[tcf-dev] Kepler RC1 Release

Martin.Oberhuber@xxxxxxx (Oberhuber, Martin) — Wed, 22 May 2013 12:49:53 GMT

Hi all,

I have taken yesterday’s build #473 from Hudson and put it on our milestone repo for Kepler RC1.

P2 Repository:

http://download.eclipse.org/tools/tcf/builds/development/milestones/20130521/

Download:

http://download.eclipse.org/tools/tcf/builds/development/milestones/20130521/org.eclipse.tcf.repo.zip

Thanks Uwe for fixing the copyright years in Target Explorer.

There’s probably a little bit more cleanup work to do for RC2, but I’d really like to branch off early with an

“1.1” branch on Monday next week already, such that we’re done early for Kepler. The same branching

should be done for the agent repository.

Please let me know of any pending must-fix work for Kepler.

Thanks,

Martin

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85 fax +43.662.457915.6

From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Monday, May 06, 2013 5:59 PM
To: TCF Development (tcf-dev@xxxxxxxxxxx)
Subject: [tcf-dev] Kepler M7 Release

Hi all,

I have tentatively taken Saturday’s build #456 from Hudson and put it on our milestone repo for Kepler M7:

http://download.eclipse.org/tools/tcf/builds/development/milestones/20130506/

Please let me know if there’s any issue with this build that would force us to resubmit to the Simultaneous Release.

Otherwise, I’d appreciate if somebody could tag the git repo with a tag for kepler m7.

Thanks,

Martin

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85 fax +43.662.457915.6

[tcf-dev] Preparing for Kepler Endgame

Martin.Oberhuber@xxxxxxx (Oberhuber, Martin) — Fri, 17 May 2013 09:01:49 GMT

Hi TCF Committers,

Eclipse Platform is planned to deliver its first release candidate for Kepler today (RC1), and with that the “endgame” towards Kepler officially starts. Some other important dates:

May 24/2013 - Deadline to submit IP Logs for Kepler releases
June 5/2013 - PMC-approved Review materials submitted to EMO
June 12/2013 - Kepler Uber Release review
June 26/2013 - Kepler release

As you see there’s quite some time between submitting release review materials and the actual release. I don’t want TCF development to be “frozen” during that time so we should consider creating a branch for Kepler maintenance very soon.

But before there’s a little bit of work to be done towards the release – I’d appreciate any help from you guys:

1. Features: Ensure that everything is stable and solid, and any pending “half done” work is finished. Please let us know here on the mailing list of any problems with “finishing up” by end of next week latest; we’d have to branch off if there are any issues.

a. Documentation: Finish / review Javadocs of any new Services or API’s.

b. Brush up the docs of any new concepts (as visible on the Web or the Wiki).

c. Any inbound contributions that require an IP-Log entry / CQ review must be done and finished by end next week.

2. Cleanup – START NOW please:

a. Ensure that the “Copyright Years” of any visible branding items, features, or file comments have “2013” when the file (or a file of the feature) was modified in 2013.

b. Ensure that Strings are externalized, obsolete strings are removed from Properties, Imports are cleaned up, version ranges are checked. JDT offers some wizards for these kinds of cleanup.

c. Key conflicts and other errors logged: Test TCF in some wider context – I’d recommend the “Eclipse for Automotive” package as testbed since that includes both CDT and JDT (which we may see with several larger accounts). Look for errorlog entries and clean up what’s possible to cleanup.

3. IP Review:

a. Please check the IP Log for completeness – Contributors check whether your contributions are mentioned; let me know of anything obsolete that should be removed.
http://www.eclipse.org/projects/ip_log.php?projectid=tools.cdt.tcf

This kind of work is important for “being a good citizen” in the Eclipse Ecosystem, and the yearly release train is a good chance to do this kind of cleanup once in a year. Kepler is also a chance for us to do some press / marketing work, so we should work good in the bigger environment.

It’s important that we start this kind of cleanup work now.

I’ll ping you again as I start working on “New and Noteworthy” and other material for the Release Review.

Let me know if there’s any questions.

Thanks,

Martin

Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River

direct +43.662.457915.85 fax +43.662.457915.6

Re: [tcf-dev] Stack trace evaluation in the UI

eugene.tarassov@xxxxxxx (Eugene Tarassov) — Tue, 14 May 2013 19:51:39 GMT

Hi Benoit,

> Shouldn't this 'caller instruction address' be returned by the agent instead?

It would be good, though I don't really know how compute a real 'caller instruction address'. I don't think gcc provides enough debug info to make it possible.

Anyway, I would not worry too much about this, because, as far as I know, gdb does the same - lookups line info using PC-1 - and users seem to be happy with that.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Benoit Perrin
Sent: Tuesday, May 14, 2013 7:33 AM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Stack trace evaluation in the UI

Hi,

I think that for some architectures (MIPS, SPARC) the (return address - 1) is
not within the caller instruction range, but in an extra instruction executed by
the CPU pipeline just after the branch instruction.

Moreover, in some cases the code does not respect the ABI and tweaks the return
address to point to the beginning of another function. In that case the (PC - 1)
computation by the client would lead to a wrong scope.

Shouldn't this 'caller instruction address' be returned by the agent instead?
The client could use this value if available or compute its own if it is was
provided by the agent.

Benoit

On 05/14/2013 12:57 AM, Eugene Tarassov wrote:
> Hi Christophe,
>
> The rationale behind it goes like this:
> Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.
>
> Regards,
> Eugene
>
>
> -----Original Message-----
> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
> Sent: Monday, May 13, 2013 3:01 AM
> To: TCF Development
> Subject: [tcf-dev] Stack trace evaluation in the UI
>
> Hi,
>
> I've been working on a stack trace problem recently and found a probable
> cause in the UI. Here is a log of the UI evaluating a stack trace:
>
> 448.180 Out: C 173 StackTrace getContext ["FP0.tracker0.ctx169"]
> 448.180 Inp: R 173
> [{IP:266729288,ID:"FP0.tracker0.ctx169",Level:0,ProcessID:"tracker0.ctx168",ParentID:"tracker0.ctx169"}]
> null
> 448.181 Out: C 174 LineNumbers mapToSource "tracker0.ctx168" 266729287
> 266729288
> 448.181 Out: C 175 Symbols findByAddr "tracker0.ctx168" 266729287
> 448.181 Inp: R 174 null []
> 448.182 Inp: R 175 null
> "@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> 448.182 Out: C 176 Symbols getContext
> "@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> 448.182 Inp: R 176 null
> {Name:"__libc_start_main",TypeClass:8,UpdatePolicy:0,Class:3,Address:266729064,ID:"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",OwnerID:"tracker0.ctx168",Size:224}
>
> I'd like to understand why the UI looks for the symbol at pc -1 instead
> of pc?
>
> Because of the minus one, the stack trace finds the frame in a specific
> function when it should not:
>
> __libc_start_main starts at 266729064 with size 224
> pc in __libc_start_main equals to pc < (266729064 + 224)
> so while it's false for pc = 266729288, it's true for pc = 266729287
>
> Any reason it's done that way? Thanks for your help.
>
> - Christophe
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/tcf-dev
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/tcf-dev
>

--
Benoit Perrin, Senior Member of Technical Staff, Wind River
direct +33 297.427.375
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [tcf-dev] Stack trace evaluation in the UI

eugene.tarassov@xxxxxxx (Eugene Tarassov) — Tue, 14 May 2013 19:44:47 GMT

Hi Martin,

> So what you'd really want is computing the "previous instruction". But doing just PC-1 won't give you that on architectures with variable instruction length.

This irrelevant which byte of an instruction to use (first or last) to lookup symbol info - as long as all bytes of the instruction belong to same function and same source line, which should always be the case.

> but what about the stacktracing code that wants to accurately compute the assembly return address ?

That code is not affected. PC-1 value is only used by the Debug view to build stack frame node label.

> were you planning to document that behavior in the TCF API Docs ?

This does not affect any API. The value is computed and used internally by the Debug view.

Regards,
Eugene

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: Tuesday, May 14, 2013 6:17 AM
To: TCF Development
Subject: Re: [tcf-dev] Stack trace evaluation in the UI

Hi Eugene,

I'm still a little confused.

So what you'd really want is computing the "previous instruction". But doing just PC-1 won't give you that on architectures with variable instruction length. I know that on Intel at least, it is very nontrivial to compute the "previous instruction address".

I understand that doing PC-1 might give you the expected line number from the ELF/Dwarf debug info ... but what about the stacktracing code that wants to accurately compute the assembly return address ?  And what about debugging scenarios where no debug info is available ?

If the stack crawl knows that the UI consistently always does PC-1 already that might work, though it feels strange ... were you planning to document that behavior in the TCF API Docs ?
Since it looks like any implementer of a stack crawl would need to be aware of that peculiar behavior, right ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
Sent: Tuesday, May 14, 2013 3:08 PM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Stack trace evaluation in the UI

On 5/14/2013 12:57 AM, Eugene Tarassov wrote:
> The rationale behind it goes like this:
> Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.

Makes sense. Thanks Eugene for explaining!

- Christophe
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

Re: [tcf-dev] Stack trace evaluation in the UI

benoit.perrin@xxxxxxx (Benoit Perrin) — Tue, 14 May 2013 14:33:20 GMT

Hi,

I think that for some architectures (MIPS, SPARC) the (return address - 1) is not within the caller instruction range, but in an extra instruction executed by the CPU pipeline just after the branch instruction.

Moreover, in some cases the code does not respect the ABI and tweaks the return address to point to the beginning of another function. In that case the (PC - 1) computation by the client would lead to a wrong scope.

Shouldn't this 'caller instruction address' be returned by the agent instead? The client could use this value if available or compute its own if it is was provided by the agent.

Benoit

On 05/14/2013 12:57 AM, Eugene Tarassov wrote:

Hi Christophe,

The rationale behind it goes like this:
Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
Sent: Monday, May 13, 2013 3:01 AM
To: TCF Development
Subject: [tcf-dev] Stack trace evaluation in the UI

Hi,

I've been working on a stack trace problem recently and found a probable
cause in the UI. Here is a log of the UI evaluating a stack trace:

448.180 Out: C 173 StackTrace getContext ["FP0.tracker0.ctx169"]
448.180 Inp: R 173
[{IP:266729288,ID:"FP0.tracker0.ctx169",Level:0,ProcessID:"tracker0.ctx168",ParentID:"tracker0.ctx169"}]
null
448.181 Out: C 174 LineNumbers mapToSource "tracker0.ctx168" 266729287
266729288
448.181 Out: C 175 Symbols findByAddr "tracker0.ctx168" 266729287
448.181 Inp: R 174 null []
448.182 Inp: R 175 null
"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
448.182 Out: C 176 Symbols getContext
"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
448.182 Inp: R 176 null
{Name:"__libc_start_main",TypeClass:8,UpdatePolicy:0,Class:3,Address:266729064,ID:"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",OwnerID:"tracker0.ctx168",Size:224}

I'd like to understand why the UI looks for the symbol at pc -1 instead
of pc?

Because of the minus one, the stack trace finds the frame in a specific
function when it should not:

__libc_start_main starts at 266729064 with size 224
pc in __libc_start_main equals to pc < (266729064 + 224)
so while it's false for pc = 266729288, it's true for pc = 266729287

Any reason it's done that way? Thanks for your help.

- Christophe

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev


--
Benoit Perrin, Senior Member of Technical Staff, Wind River
direct +33 297.427.375

Re: [tcf-dev] Stack trace evaluation in the UI

Martin.Oberhuber@xxxxxxx (Oberhuber, Martin) — Tue, 14 May 2013 13:17:06 GMT

Hi Eugene,

I'm still a little confused.

So what you'd really want is computing the "previous instruction". But doing just PC-1 won't give you that on architectures with variable instruction length. I know that on Intel at least, it is very nontrivial to compute the "previous instruction address".

I understand that doing PC-1 might give you the expected line number from the ELF/Dwarf debug info ... but what about the stacktracing code that wants to accurately compute the assembly return address ?  And what about debugging scenarios where no debug info is available ? 

If the stack crawl knows that the UI consistently always does PC-1 already that might work, though it feels strange ... were you planning to document that behavior in the TCF API Docs ? 
Since it looks like any implementer of a stack crawl would need to be aware of that peculiar behavior, right ?

Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River
direct +43.662.457915.85  fax +43.662.457915.6

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
Sent: Tuesday, May 14, 2013 3:08 PM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Stack trace evaluation in the UI

On 5/14/2013 12:57 AM, Eugene Tarassov wrote:
> The rationale behind it goes like this:
> Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.

Makes sense. Thanks Eugene for explaining!

- Christophe
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev

Re: [tcf-dev] Stack trace evaluation in the UI

christophe.augier@xxxxxxx (Christophe Augier) — Tue, 14 May 2013 13:07:53 GMT

On 5/14/2013 12:57 AM, Eugene Tarassov wrote:

The rationale behind it goes like this:
Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.


Makes sense. Thanks Eugene for explaining!

- Christophe

Re: [tcf-dev] Stack trace evaluation in the UI

eugene.tarassov@xxxxxxx (Eugene Tarassov) — Mon, 13 May 2013 22:57:19 GMT

Hi Christophe,

The rationale behind it goes like this:
Since it is not a top frame, PC is return address - it points to an instruction after call instruction, and PC-1 is address of last byte of the call instruction. So, to lookup a caller, PC-1 is used. In other words, we want to show a function that owns the call instruction. Same is done with line number info. Actually, it is done mostly because of the line number info - most users want see line that contain the call, not the line which contains return address.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
Sent: Monday, May 13, 2013 3:01 AM
To: TCF Development
Subject: [tcf-dev] Stack trace evaluation in the UI

Hi,

I've been working on a stack trace problem recently and found a probable
cause in the UI. Here is a log of the UI evaluating a stack trace:

448.180 Out: C 173 StackTrace getContext ["FP0.tracker0.ctx169"]
448.180 Inp: R 173
[{IP:266729288,ID:"FP0.tracker0.ctx169",Level:0,ProcessID:"tracker0.ctx168",ParentID:"tracker0.ctx169"}]
null
448.181 Out: C 174 LineNumbers mapToSource "tracker0.ctx168" 266729287
266729288
448.181 Out: C 175 Symbols findByAddr "tracker0.ctx168" 266729287
448.181 Inp: R 174 null []
448.182 Inp: R 175 null
"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
448.182 Out: C 176 Symbols getContext
"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
448.182 Inp: R 176 null
{Name:"__libc_start_main",TypeClass:8,UpdatePolicy:0,Class:3,Address:266729064,ID:"@M0.@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",OwnerID:"tracker0.ctx168",Size:224}

I'd like to understand why the UI looks for the symbol at pc -1 instead
of pc?

Because of the minus one, the stack trace finds the frame in a specific
function when it should not:

__libc_start_main starts at 266729064 with size 224
pc in __libc_start_main equals to pc < (266729064 + 224)
so while it's false for pc = 266729288, it's true for pc = 266729287

Any reason it's done that way? Thanks for your help.

- Christophe

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.